* James M Snell <[EMAIL PROTECTED]> [2005-07-12 23:20]:
> 1. Comments can either be included directly within the feed or in a
> separate feed.
> 2. Comment entries are distinguished by a link @rel="in-reply-to"
> @href="{$original-entry/atom:id}"
> 3. Comment feeds may be indicated using a link @rel="comments"
> @href="{$comment-feed-url}" as a child of <feed />
Sounds good to me.
> Example 1: Entries and comments in a single feed
>
> Example 2: Comments in a separate, associated feed
Yep.
> The in-reply-to link could also be used in feeds that are not
> directly associated with the source feed. e.g. if you post an
> entry in your blog and I post a reply to that entry in my blog.
> My entry can use the in-reply-to link so that thread aware
> readers can make the connection appropriately.
Hmm. That’s a nice thought that hadn’t occured to me. Thinking
about it, that would offer a way to solve a lot of the mess that
currently plagues the Trackback/Pingback mechanisms. You could
just ping the target weblog with a pointer to the feed which
contains the entry you wrote in response to someone else’s post.
See also below, in reply to Thomas Broyer, on @rel='related'.
It also occurs to me that just like in email (examine the
specimen you’re just reading, f.ex.), there’s nothing that
precludes an entry from having *multiple* @rel='in-reply-to'
links, although in practice this will be rare. Or at least
newsreaders will probably not support it well (like mailers
don’t, even when they thread messages and can send replies to
multiple messages at once – mutt, which I’m sending this message
with, being a fine example), which dooms it to be a rare
situation, anyway. But there’s no particular reason to confine
conversations to trees rather than allowing full directed graphs,
and so long as aggregators are aware that they MAY encounter
multiple backreferences, it’s probably fine for them to do the
same as threading mailers: pick one of the backreferences for the
purpose of threading and ignore the others.
> Question: could the @rel="comments" link be handled
> appropriately using the existing @rel="related"? The question
> hinges on whether or not it is semantically important to
> distinguish "comments" from other types of related entities.
> I'm not convinced it is.
You have a point… hmm…
@rel='comments' does seem to stem from an arbitrary narrow world
view: it’s kind of stupid unless we are going to specify that the
referenced feed MUST contain ONLY comments – because what if
someone points to a feed which contains unrelated entries? No
harm would be done anyway (most probably, the aggregator would
ignore anything in the purported comment feed that’s not a
comment linked to things in the main feed), but as a description
of the relationship “comments” would be silly.
> If a @link="related" points to an Atom feed, who cares what
> that feed contains, the user agent can make the feed available
> for the user to subscribe to pulling in the relevant entries.
The problem I have with this is that it gives the aggregator a
bit too little to work with. Thread-aware aggregators will
probably want to subscribe a comments feed automatically –
possibly even without user intervention (f.ex. in the case of a
web-based aggregator like Bloglines). But a related feed could be
anything. How does the aggregator know whether it needs to
examine one of these for comments, and if so, which one?
Something more specific than @rel='related' is clearly necessary
to facilitate machine consumption by thread-aware aggregators.
Maybe it should be @rel='has-comments'? Or am I splitting hairs
now?
* Thomas Broyer <[EMAIL PROTECTED]> [2005-07-13 00:00]:
> As an atom:id is an identifier that might (should?) not be
> "dereferenceable", atom:link is not a good choice.
There is nothing in the spec that forbids atom:link from being
dereferencable, nor anything that advises against it being so.
See 4.2.6 and 4.2.6.1 in -09.
In fact, Tim Bray has argued that you should go ahead and use
HTTP URIs as IDs:
http://www.tbray.org/ongoing/When/200x/2004/05/28/LinksAndGuids
The spec just says is that the URI MUST NOT be assumed to be
dereferencable, and that the exact value must be considered
opaque: “http://EXAMPLE.COM/foo” is different from
“http://example.com/foo” for the purposes of identifying entries.
Therefore, the spec says, URIs SHOULD be normalized according to
the strategy laid out therein in order to avoid confusion.
That is all.
Whether atom:link is a bad choice for carrying a non-
dereferencable URI around is a better argument. The spec says,
verbatim:
The "atom:link" element defines a reference from an entry or
feed to a Web resource.
That would seem to imply dereferencability, but is open to
interpretation. The spec itself goes on to leave matters at the
following:
The "href" attribute contains the link's IRI. atom:link
elements MUST have a href attribute, whose value MUST be a
IRI reference [RFC3987].
That does not mandate any particular interpretation – URIs may be
dereferencable, but don’t have to be.
Personally, I would prefer to interpret the spec liberally, if
that is within the intended spirit, because a new @rel value
requires very little work and seems more likely to gain traction.
Consumers in particular have a large enough burden implementing
threading and threaded display anyway. (For producers, it makes
much less of a difference.)
> 3. Comment feeds may be indicated using a link @rel="comments"
> @href="{$comment-feed-uri}". If used as a child of atom:feed,
> it links to a feed containing all comments on all entries. If
> used as a child of atom:entry, it links to a feed containing
> only the comments on the entry.
Yep. No reason to pick sides here.
> >The in-reply-to link could also be used in feeds that are not
> >directly associated with the source feed. e.g. if you post an
> >entry in your blog and I post a reply to that entry in my
> >blog. My entry can use the in-reply-to link so that thread
> >aware readers can make the connection appropriately.
>
> Your entry should also link to a representation of the
> "commented resource" using an atom:[EMAIL PROTECTED]"related"].
I really like this! That would give aggregators the chance to do
something sensible when an entry shows up in a feed which is
in-reply-to an entry in another feed which the particular
aggregator does not subscribe.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
