* Antone Roundy <[EMAIL PROTECTED]> [2005-08-01 18:30]:
> On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote:
> >This undermines the purpose of the link.
>
> I'd say that not being able to tell whether @href in
> [EMAIL PROTECTED]"in-reply-to"] is dereferencable or not is what
> undermines link.
It undermines the purpose of the link insofar as IMO the entry
being replied to MUST ALWAYS be identified by its atom:id. I am
strongly -1 on letting the producer choose to identify it by its
network location in any way or shape. Such a location is valuable
as additional information to provide, but it’s strictly optional.
> If "If the resource being replied to is an atom:entry, the
> value of the href attribute MUST be the atom:id of the
> atom:entry" doesn't sound like a good rule, then I'd argue that
> using atom:link to identify the resource being replied to is a
> bad idea.
I have already agreed about the fact that atom:link is not the
right vehicle for carrying the atom:id, so there’s no need for
you to preach to the choir. See my "Thread/comment extension
refactoring" post about my current stance.
As for overloading @rel='in-reply-to' to carry either
dereferencable URIs or atom:ids, that would just needlessly
require conditional checks on the consumer end. And because I’m
strongly -1 on omitting the atom:id but also no longer consider
atom:link to be the right place for it, the idea is triply wrong.
> >Atom Entry Documents can move around; their IDs are eternal.
> True, so you could just omit @type from this link if you're
> concerned that your entry document might move. Or we could go
> with something like this:
>
> <ext:in-reply-to id="...">
> <atom:link rel="found-in-entry-document" href="..." />
> <atom:link rel="found-in-feed-document" href="..." />
> </ext:in-reply-to>
That makes the information in the nested atom:link elements
inaccessible to compliant clients without threading support, and
it also requires new relationships to boot. Also, note that
entry-sources vs replied-to-entries is an 1:N relationship, so it
would make sense to group replied-to-entries by entry-source,
rather than vice versa.
So then you have
<link rel="via" type="application/atom+xml" href="http://example.com/feed/";>
<thr:source-for>urn:foo:1</thr:source-for>
<thr:source-for>urn:foo:2</thr:source-for>
</link>
which properly reuses a known relationship, so that even a
non-thread-aware consumer can do something interesting with the
information, even if it does not understand it quite as precisely
as a client with proper thread awareness.
Again, see my "Thread/comment extension refactoring" post about
my current thinking.
> ...okay, that last sentence suggests that what I propose just
> above here is a superior way to having possibly-derefencable
> atom:links, because you could update the
> found-in-entry-document link if it got out of sync with the
> location of the document. Otherwise, we'll have to be limited
> to linking to the feed in which the entry is found.
I don’t see why that is an advantage specific to using the @type
attribute on atom:link in the way you proposed, rather than
a benefit that *any* approach for including a source URL would
provide.
Again, please see my other post. The approach we started with
(relying mostly on @rel='in-reply-to' which I proposed) was
hackish, which was okay as long as it was minimal, but is no
longer tenable now that we are trying to accomplish even a bit
more. My new proposition deals with all of your objections and
several other issues I ran across on my own.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
