> I have no idea what you mean by "not precise enough to be used". What > makes them imprecise?
The very fact they don't represent a state that can be trusted. As the spec says they are not the true value but the true value at one given time. > Look at just about piece of blogging software that accepts comments and > on the front page you'll typically see a link that specifies the number > of comment received for that entry. It may, or may not be an accurate > count, but it serves a useful purpose. Why is the same metadata not > useful in an entry/feed? Well to take your example a bit further. Say I'm following comments posted to an entry, since there is no way for me to decide if the number provided by the extension is the most up-to-date, I will have to manually go to the source itself and check if someone replied since my last visit. How is that useful to me as an user? Besides you do not answer the question of HTTP caching I mentionned. Basically it would break most planets out there which rely heavily on the '304 Not Modified' status code to check if a feed has been modified. In this case a server such as Apache would respond: "well yes the file has changed on the disk so here it is" when in fact the content of the feed has only changed for the number of comments of an entry. Clients could of course work around such issue but this is a rather big problem to me. > The ref attribute is the unique identifier of the resource being > responded to. It doesn't make make sense to respond to a Feed. Common sense is one thing, being clearly specified is another one. - Sylvain
