2006/5/2, James M Snell <[EMAIL PROTECTED]>:
Regarding the ref vs. href, issue, I really want to discourage client implementors from using the thr:replies as a link to the comment feed.
Why?
From what I read this week in other threads (about cloning the
atom:link element, etc.), I think it could work. 1. define a "replies" link relation, so there is an atom:link pointing to the replies feed 2. define a thr:replies element with an @href and additional metadata (count, updated), clients are invited to use the thr:replies/@href and *not* to try to match the thr:replies element with an atom:[EMAIL PROTECTED]"replies"] ; if a "reader" processes thr:replies elements it should then ignore each and every atom:[EMAIL PROTECTED]"replies"]. Step 1 is either optional (do not define this "replies" link relation) or mandatory (require that there is an atom:[EMAIL PROTECTED]"replies"] matching each thr:replies element). Those three elements would have equivalent meaning, the last one adding extra metadata: <atom:link rel="replies" href="comments.atom" /> <thr:replies href="comments.atom" /> <thr:replies href="comments.atom" count="5" updated="2006-05-05T00:38:00+01:00" /> Things would have been far easier if either a) atom:link were extensible or b) xml:base wasn't allowed on every element but only on "sections" (namely, atom:feed, atom:entry and atom:content) that can be included from other documents, so that you don't have to rewrite relative IRIs (I think that's the original rational behind xml:base), but that's not the case… To conclude, I think using attributes directly on atom:link is the thing to do, waiting for an amendment to RFC4287 to invite processors/parsers not to discard that extra metadata. The other choice is to totally remove those attributes, which is what you finally chose, I can't blame you. -- Thomas Broyer
