Sorry for the delay in commenting, but I only got around to looking at this
in detail today.
Other than a few areas that I think need clarification in the wording, my
main problem with this proposal is the dereferenceable in-reply-to. While I
can see why a feed producer may want to include it, I don't see how an Atom
processor can do anything useful with it (which couldn't be done just as
easily with existing elements). And if it's not of any use, it seems to be
that it's just taking up space and complicating the spec.
The easiest way to explain my position is with some use cases. Let's say you
wanted to reply to a particular item in another Atom feed:
<thr:in-reply-to
type="application/atom+xml"
idref="tag:someatomid"
source="http://www.example.org/someatomfeed"/>
From that alone I can do all sorts of fancy threading in my client (assuming
the user is subscribed to the source feed) and/or provide a
button/link/whatever allowing the user to subscribe to the source feed (if
he isn't already).
If the item being replied to is in the same feed as the reply then the idea
is pretty much the same except no source attribute is required. That's all
good.
Now let's say I wanted to reply to a particular item in an RSS feed. Here's
what I'd expect:
<link
rel="related"
type="text/html"
href="http://www.example.org/rsspermalink.html"/>
You could use an in-reply-to tag, but it's not going to be any more useful
to me than that (in some cases, less useful). Even with an idref of some
sort, I still can't thread such a reply. The original article can't link to
my reply as part of its own threading system and nobody reading the original
thread can reply to my reply and still have it be part of the original
thread.
The bottom line is that it's really not part of a thread - it's a completely
separate message that is merely related to the original. In fact, if you
were to represent that link as a <thr:in-reply-to> element, the best I could
do as a client is convert it into a "related" link or a "via" link.
Basically what it comes down to is this. I think <thr:in-reply-to> should be
reserved for threading of atom entries only. Any other replies should be
referenced with a "related" or "via" link element. There's no need for a
type since it should always be "application/atom+xml". The source should
always point to an Atom feed or, if blank, should imply the current feed.
I don't have any issues with the <replies> element although I think it would
be nice to show examples of the two main use cases: namely the equivalent of
RSS <comments> (basically type="text/html") and the RSS <wfw:commentRSS>
extension (type="application/atom+xml").
For now I'm going to ignore all the other little issues I have with the
proposal on the off chance that you come around to my way of thinking. Once
you throw out inReplyToDereferenceable the whole thing becomes a lot simpler
and most of those problems should solve themselves.
Regards
James
James M Snell wrote:
At some point over the next couple of days, a slightly modified version of
the comments extension draft [1] will be published. The moment it
publishes will kick off a two week Unofficial Last Call period for the
spec. The spec has been stable of the past two months with no major
issues raised. Please review the draft. After two weeks I will review
any received feedback and, if appropriate, cut a new draft which will
become the stable version. After the Atom Protocol work completes, I will
submit the stable version of the draft as a standards track RFC.
