* Antone Roundy <[EMAIL PROTECTED]> [2005-07-12 21:25]:
> If you're already creating an extension link type, why not
> throw in an additional attribute too to help with that:
>
> <feed xmlns:comments="http://example.org/commentfeed";>
> <entry>
> <link rel="comments" comments:updated="2005-07-12T12:53:15Z"
> href="http://example.com/commentsfeed.xml"; />
> </entry>
> </feed>
>
> Then you'd only need to poll the main feed unless it indicated
> an update in the comment feed.
Note that this makes it impossible to keep up with comments
posted to entries which have slipped off the bottom of the feed.
> Of course, if comments were threaded, you have to cascade
> comments:updated values up through all the feeds in a thread,
> and aggregators would have to follow updates back the other
> way, potentially down multiple branches, to find all the
> updated leaves.
Ugh. The complexity of implementing this, particularly on the
consumer end with the combination of multiple network fetches and
condition checks intertwined, sounds seriously appaling to me.
> ...which raises the question of whether an application like
> this might beg a minimal feed for comments that simply pointed
> to an Entry Document for each comment. Entries in such a feed
> would really only require an atom:id, atom:updated, atom:link
> pointing to the entry document, and atom:link pointing to the
> parent comment or entry.
Hmm. I don’t really like this either, because it involves so many
documents. People who produce static files for their feeds would
have to contend with an ocean of piddly Entry Document files.
But it reminded me that atom:link is actually sufficient for what
I said an extension element would be needed in my post – since
atom:id contains a URI anyway, you can just say
<entry>
<link rel="in-reply-to" href="{$original-entry/atom:id}" />
<!-- ... -->
</entry>
> atom:title could conceivably be considered undesirable bloat
> for such a feed.
I suppose. If you actually inline the comments rather than
pointing to them, though, in the way I outlined, it’s not
undesirable at all. A lot of sites/weblog engines allow including
an (optional or not) title with a comment. And even if not, it
would lend itself to including something like
<title>Re: <xsl:value-of select="$original-entry/atom:title" /></title>
for the benefit of non-thread-aware aggregators.
> Is Atom the right format for this need? An alternative might be
> to define a format for this need that used Atom elements but
> had minimalized cardinality requirements.
That’s a really drastic measure for such negligible benefit.
One Format To Rule Them All, as far as I’m concerned.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
