>>[snip] >>> - We're talking about adding machine-parsable data that would be >>> invisible to readers of the post content >> >> I don't know. The specification says nothing about that. Presumably, >> the implementers that have already deployed know what they are for. >> > > Machine-parseable data that may or may not be presented to users. The > spec is silent on how the metadata should be used because there is no > reason to dictate how it should be used. Implementations should use it > in whatever way they feel is most appropriate. >
I'm sorry to stir this up again but I've read once more the last FT draft and I still cannot understand the use of the thr:count and thr:when attributes. Well in regards to the context they sit I see their meaning but I cannot see their value. If a feed containg FTE information is meant to be handled by machines only, then those values are not precise enough to be use (but I'd be happy to gearing about them though). If those values are to be presented to users, they are also not precise to have any interest. 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. Anyway, I do not see the value brought by thr:count and thr:when alltogether. Since it is a MAY as well, I hardly see the point of keeping them. 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. Should the link be ignored? Should an error be raised? I assume the former but sadly the spec is not helping in this case. 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. - Sylvain
