* 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/
