Hmm.. I think what this boils down to is a question about whether or not
the replies extension really does need to support replies to non-Atom
resources at all. I can see it both ways. I definitely understand
where you are coming from, but I also don't want to have to look in two
different places for the same basic type of information if the only
difference is what data format is being referenced.
Let me stew on this. If you have any specific language you'd like to
see in the spec, please go ahead and send it my way.
- James
James Holderness wrote:
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.
