* Antone Roundy <[EMAIL PROTECTED]> [2006-05-18 20:05]: > and in another document: > > <ct:comment-tracking xmlns:ct="..." xmlns:atom="..." ...> > <atom:link rel="related" href="URL of the feed" ... /> > <ct:entry ref="foo"> > <atom:link rel="comments" href="..." type="..." > hreflang="..." ct:count="5" ct:when="..." /> > <atom:link rel="comments" href="..." type="..." > hreflang="..." ct:count="3" ct:when="..." /> > </ct:entry> > <ct:entry ref="bar"> > <atom:link rel="comments" href="..." type="..." > hreflang="..." ct:count="0" ct:when="..." /> > <atom:link rel="comments" href="..." type="..." > hreflang="..." ct:count="1" ct:when="..." /> > </ct:entry> > ... > </ct:comment-tracking> > > Of course the comment tracking document wouldn't only be > authoritative for feeds that pointed to it with a > comment-tracking link. > > This would require an extra subscription to track the comments, > as well as understanding an additional format (as opposed to > just an additional extension--either approach requires SOME > additional work), but it would prevent unnecessary downloads by > clients that aren't aware of it, and would reduce the bandwidth > used by those that are. > > This approach could be generalized to enable offloading of > other metadata that's more volatile than the entries > themselves.
Actually, you don’t really need another format. There’s no reason why you couldn’t use atom:feed in place of your hypothetical ct:comment-tracking. :-) Your ct:entry elements could almost be atom:entry ones instead, too, except that assigning them titles and IDs feels like overkill. The real cost is not the cost of an extra format, but that implementations then need to understand the FTE in order to know to poll an extra document to retrieve the out-of-band metadata. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
