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.
- James
Antone Roundy wrote:
On Saturday, July 30, 2005, at 03:59 PM, A. Pagaltzis wrote:
I’d prefer to eliminate the one contra you listed by using an
extension element for this purpose (as always, nested into the
link.) Of course, that means need a namespace…
Given that the link to the feed is traversable, and the "link" to the
ID of the entry may not be, I'd suggest using an extension element for
the possibly-non-traversable link, if for either....which would leave
us needing to pick a good @rel value for the traversable one. That
would also keep my con point around:
<foo:non-traversable-reference id-of-other-entry="...">
<link ... />
</foo:non-traversable-reference>
...unless it were done this way:
<link ...>
<foo:non-traversable-reference id-of-other-entry="..." />
</link>
...but doesn't quite work, because the logical relationships between
the elements are entry to foo:non-traversable and foo:non-traversable
to link, not entry to link and link to foo:non-traversable.
I'm satisfied to live with the negative point of having a link in an
unexpected place. And since I don't like non-traversable atom:links,
I myself prefer <foo:non-traversable><link/></foo:non-traversable>,
though I don't expect it to be adopted.
