* 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,
