Tuesday, April 11, 2006, 9:20:32 PM, James M Snell wrote:
> I also added a new warning for implementors: "Implementors should note
> that while the Atom Syndication Format does not forbid the inclusion of
> namespaced extension attributes on the Atom link element, neither does
> is explicitly allow for such extensions. The result of this is that the
> thr:count and thr:when attributes fall outside of the guidelines for
> Atom extensions as defined in Section 6 of [RFC4287] and may not be
> supported by all Atom implementations."
[Apologies to everyone for flogging this dead horse some more. I'm
only doing this, because I care.]
I'll quote your argument from MDP's blog and comment here, rather than
on his dead comment thread, if that's ok:
> Ironically, the primary reason for using link for "replies" is
> because it makes very little sense to duplicate the function of the
> link element. I considered a thr:replies element. Ultimately, it
> would have looked and acted darn near identical to the atom:link
> element (with attributes like type, href, hreflang, etc). One needs
> to consider whether or not it makes sense to introduce a new
> namespaced extension element that duplicates the basic function of
> atom:link just to support the addition of two *optional* and *purely
> advisory* attributes.
You recognize the fact that adding non-standard attributes on
atom:link isn't going to be fully interoperable (that the thr:count
and thr:when attributes might not make it from producer to consumer
intact), but still prefer to make "replies" a link element on the
basis of style and convention.
This seems to be the wrong priority to me.
Replacing <atom:link rel="replies"> with an otherwise identical
<thr:replies> element would fix the interop problem, and wouldn't
introduce any other problems that I can think of. The only reason to
keep the current link element is because it somehow looks better, or
saves copy/pasting the relevant bits of the atom:link spec into the
draft.
In terms of the considerations to the interoperability of running
code, thr:replies seems to beat atom:link in every way. It even
manages to be more concise (you don't need the @rel), and you wouldn't
need to put thr:count and thr:when into a namespace (namespaced
attributes confuse people).
Eg:
<thr:replies type="application/atom+xml"
href="http://www.example.org/mycommentsfeed.xml";
count="10"
when="2006-02-20T00:00:00Z" />
instead of:
<link rel="replies"
type="application/atom+xml"
href="http://www.example.org/mycommentsfeed.xml";
thr:count="10"
thr:when="2006-02-20T00:00:00Z" />
I don't really buy the justification that the attributes don't matter,
so it is ok if they get lost btw. If I was using an API that didn't
give access to the count attributes, I'd probably be a bit miffed, I'm
unlikely to say "oh it doesn't matter cause they were only advisory,
I'll just load the comments feed, parse the XML, etc, etc, instead".
Yes, thr:count is derived, so it isn't essential, but this doesn't
mean that it isn't useful. It is obviously useful, else it wouldn't be
in the draft.
--
Dave
