On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote:
* Antone Roundy <[EMAIL PROTECTED]> [2005-07-31 01:15]:
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.
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.
The primary purpose of [EMAIL PROTECTED]"in-reply-to"] is to identify the
resource (which may be an atom:entry) being replied to. If that
resource is an atom:entry, then the appropriate identifier for it is
it's atom:id.
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.
As I've said before, I think that stuffing data that happens to be a
URI but may not be dereferencable into link/@href is a bad idea. If we
ARE going to do it, then I think we need a way to at least hint at
whether it's a dereferencable link or some other data stuffed into a
link element.
Here's what the spec says @type is for:
On the link element, the "type" attribute's value is an advisory
media type; it is a hint about the type of the representation that is
expected to be returned when the value of the href attribute is
dereferenced.
If @href isn't dereferenable, then the existence of @type is deceptive.
I suppose it could mean "when I saw it, it was in some kind of Atom
document", but so what? What if the feed gets converted to RSS 2.0,
the atom:id is put into guid, and I find the entry in the RSS feed?
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>
Or we could just stick with what has been proposed, perhaps including
what I proposed in my last message, and if they entry document moves,
then oh well, the web has another broken link just as it would in what
I proposed just above here or in any case where a dereferencable link
was published, but the atom:id would still be valid. If after moving
the entry document, one were to publish the in-reply-to link again, it
would be appropriate to remove the @type attribute.
...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.
