* Tim Bray <[EMAIL PROTECTED]> [2006-05-23 23:40]: > On May 20, 2006, at 8:49 AM, David Powell wrote: > >Foreign attributes are bad, and are inherently less > >interoperable than Extension Elements. > > I would say that furious debates about elements-vs-attributes > have been going on since the dawn of XML in 1998, but that > would be untrue; they've been going on since the dawn of XML's > precursor SGML in 1986. They have never led anywhere. After > you've noticed that if you need nested element structure you're > stuck with elements, and if you don't want to have two things > with the same names attributes can help, there really aren't > any deterministic decision procedures. > > I note with pleasure that *all* known XML APIs allow you to > retrieve elements and attributes with about the same degree of > difficulty.
As I read David’s argument, this has nothing to do with elements vs attributes and everything to do with Extension Elements vs foreign markup. It doesn’t make a whiff of difference to David’s argumen whether the Feed Thread Extension standardised on providing this information as child elements or attributes of atom:link. The considerations are exactly the same: model vs syntax. ---- By and large, I agree with him that it would have been beneficial to specify Atom just a little more closely at a model level. But I also agree with you that aspiring to much higher rigor beyond the Infoset level is unnecessary. My retrospective opinion is that the correct approach would have been to specify that an Atom Feed Document consists of a series of completely independent Atom Entries, each of which can be interpreted in isolation of any others as well as of the Atom Feed Document that they are found in (modulo Person Construct inheritance). This would explicitly allow consumers to rely on this atomicity (pun intended), thus preventing any extensions from crossing these boundaries. This goes beyond the mere interchange of messages to a definition of a standardised model, though as you can see, it’s a very loose one. I contend it is also the model used implicitly by any useful aggregator which tracks feed content over time. Section 6.4 is more myopic and simultaneously more presbyopic than that. This omission shouldn’t matter much in practice. RFC 4287 enables such a world view implicitly anyway (eg. by only allowing feed metadata to appear at the top of a Feed Document and declining to assign any significance to the order of entries). Extensions which require considering an Atom Feed Document as an overall unit rather than as a collection will hopefully fail to gain much acceptance by virtue of high burden on implementors. But being explicit about this model would have made RFC 4287 a better spec. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>