2006/5/17, Sylvain Hellegouarch:
Besides, say a comment is added to the comments feed. I, as an application developer, will want to update thr:count and thr:when of the entry itself. Meaning that I will have to disregard any If-Modified-Since header sent by an aggregator to check out if my entry has changed when it has actually not changed per se.
You Atom Entry Document (representation) has changed, so Last-Modified and ETag should have changed and you have to eval If-(Not-)Modified-Since and If-(None-)Match wrt these new values. However, as the entry (resource) itself has not changed, you won't change the atom:updated value. Aggregators will do the rest. The problem, actually, is that if you don't bring the entry up in your feed, most aggregators won't see it has changed and won't update their local copies thr:count and thr:when with the actual values. But this is not related to those attributes really, you'd have the same problem if you were including the link and count/when info into the entry content (see mnot's feed for example): client apps will have local copies that they won't always update to reflect their new state. On the other hand, bring the entry up in the feed for just minor changes like these can lead to real bandwidth waste (particularly if the client doesn't support the FTE) and eventually data loss (missed entries because they've fallen out of the feed "window", particularly if the client doesn't support "paging"). This is due to the syndication model I think.
Another point is that neither your draft nor RFC 4287 seem to say what a processor, which cannot process a value of the rel attribute, should do.
It does not have to say it, this is really implementation dependent.
Should the link be ignored? Should an error be raised? I assume the former but sadly the spec is not helping in this case.
Some implementations will support only closed set of rel values (generally, at a minimum rel="alternate") and simply ignore others ; others will show all links along with their rel values. For example, these links: <link href="..." /> <link rel="via" href="..." title="Hello World! from John Smith" type="text/html" /> <link rel="replies" href="..." title="Trackbacks and Pingbacks" type="text/html" /> <link rel="replies" href="..." title="Comments" type="text/html" /> <link rel="replies" href="..." title="Comments, Trackbacks and Pingbacks" type="application/atom+xml" /> <link rel="related" href="..." title="A Picture of the Beach" type="image/png" /> could be rendered as follow (in pseudo BB code): * [url=...]alternate[/url] * [url=...]via, Hello World! from John Smith (Web Page)[/url] * [url=...]replies, Trackbacks and Pingbacks (Web Page)[/url] * [url=...]replies, Comments (Web Page)[/url] * [url=...]replies, Comments, Trackbacks and Pingbacks (Atom Feed)[/url] * [url=...]related, A Picture of the Beach (PNG Image)[/url]
Finally, if I set a <link rel="replies" ... /> into a feed element, should the ref attribute of the in-reply-to should use the id of the feed or the entry it concerns? If it is the former, aggregators won't be able to correlate threads and entries.
Is the entry replying to the feed or an entry in this feed? ;-) Actually, this is quite clear per the draft: A "replies" link appearing as a child of the Atom feed or source element indicates that the linked resource may contain responses to any of that feeds entries. Accuracy of the in-reply-to attribute values can't be enforced or even verified, in the same way that a rel="alternate" link could reference another resource, which is not an "alternate" at all. -- Thomas Broyer
