On Saturday, July 30, 2005, at 04:37 PM, James M Snell wrote:
One challenge is that for anything besides references to Atom entries,
there is no guarantee that in-reply-to links will be non-traversable.
For instance, if someone were to go and define a behavior for using
in-reply-to with RSS, the href of the link may point to the same URL
that the RSS item's link element points to (given that there is no way
to uniquely identify an RSS item).
<link rel="in-reply-to" type="text/html"
href="http://www.example.com/entries/1"; />
This is legal in the spec but is left undefined.
The natural choice of values when replying to an RSS 2.x item would be
the guid, since it's the closest counterpart to atom:id. But if the
guid is not a permalink (ie. not dereferencable), then it won't have a
MIME type, just as non-dereferencable atom:id's don't have a MIME type.
Both of these facts suggest that the following sentence should
probably be removed from section 3:
If the type attribute is omitted, it's value is assumed to be
"application/atom+xml".
Instead, I'd suggest stating that if the type attribute is omitted, the
in-reply-to link cannot be assumed to be dereferencable, and that
non-dereferencable links MUST NOT have a type attribute.
Editorial notes about this sentence:
A type attribute
value of "application/atom+xml" indicates that the resource being
responded to is an atom:entry and that the href attribute MUST
specify the value of the parent entries atom:id element.
1) "parent" probably isn't the best word here since in-reply-to isn't
being defined in terms of parents and children.
2) "entries" -> "entry's"
I could add more, but instead, here's my suggestion for replacing that
sentence:
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. If the value of
the type attribute is "application/atom+xml" then the href attribute
MUST be the (URL/URI/IRI) of an Atom Entry Document containing the
atom:entry being replied to.
Anything else could lead to inconsistencies. For example, when
replying to an atom:entry that can be found in an Atom Entry Document,
but whose atom:id does NOT point to that document, there would be
multiple choices available for the reply link's href attribute.
