* James M Snell <[EMAIL PROTECTED]> [2006-05-20 06:40]: > A. Pagaltzis wrote: > > I’d still like thr:when called thr:updated, as it follows the > > same semantics as atom:updated and its value is of the same > > type. > > I'm still stewing over this and haven't quite made up my mind > on it yet. The only reason I'm not quite comfortable with it is > that it just seems confusing have both an atom:updated and a > thr:updated.
How so? I honestly can’t follow that. Explain? > >> That is, the actual total number of responses contained by > >> the linked resource MAY differ than the number specified in > >> the thr:count attribute. Feed publishers SHOULD make an > >> effort to ensure that the meta is accurate. > > > > This SHOULD seems way too prescriptive. If you keep this > > sentence at all, I suggest changing to an informal “may want > > to.” > > "may want to" is a little too weak for me, but yes, the SHOULD > is too much. Let me think about it. If I can't come up with > something better, I'll use the "may want to" suggestion. Oh wait. I was bewildered because I read it as “Feed aggregators” rather than “Feed publishers.” Sorry! Comment retracted, the SHOULD is perfectly appropriate. > >> Feed publishers MUST consider a change to the thr:count and > >> thr:when attributes to be an "insignificant" update, meaning > >> that the value of the containing feed, entry or source > >> element's atom:updated element MUST NOT be affected by a > >> change to the values of either of these attributes. > > > > I would clarify this “an "insignificant" update in terms of > > RFC 4287”. However, I am not sure what this MUST buys, and > > more importantly, how it could be enforced. Suggesting SHOULD > > instead. > > Making this a MUST will (hopefully) reduce the likelihood > false-updates for clients that don't understand FTE. That is, > if I use a client that does not understand FTE and I suddenly > see an entry that is marked as updated for no apparent reason, > I'm likely to get quite annoyed after a while. > > (note that I included this after running some tests on a couple > of feed readers and discovered that it is indeed quite > annoying) That means it falls into the “compliance cannot reasonably be tested but non-compliance is likely to cause interop problems” bucket, which is exactly when a SHOULD is appropriate. > > This concern could be partially addressed by including an > > element to specify a global reply count for an entry in an > > atom:entry Metadata element. > > […] I could imagine feed reader implementors being quite pissed > off that they have to support an element with identical > form/function/semantics as slash:comments just so feed > publishers can avoid having to declare one additional xml > namespace. I dunno; it seems like a drop in the bucket compared to the rest of the spec, and if they’ve already implemented slash:comments semantics it seems like the effort to support an equivalent element in another extension is minimal. > Also consider that even if FTE declares a > <thr:count>5</thr:count> element, most folks are likely going > to keep on using slash:comments. (I mean, heck, look at the > number of Atom 1.0 feeds that are still using <dc:subject> to > indicate the category!!) If they were previously already using it, sure. I’m willing to bet money that next to noone who implemented Atom 1.0 support from scratch is doing that, though. Rather, I’d posit that these are (nearly?) all template-based Atom 0.3 implementations that were upgraded to Atom 1.0 with minimum effort. I believe that those who come to Atom 1.0 with a clean slate benefit from the inclusion of a native atom:category element, and likewise those who come to the FTE with a clean slate will benefit from the inclusion of a native atom:entry Metadata element equivalent to slash:comments. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
