Tuesday, May 23, 2006, 10:31:37 PM, Tim Bray wrote:
> 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. What Aristotle said. Yes, I agree, but debate over elements vs attributes in generic XML isn't relevant. > So, my conclusion: I disagree with Powell. Let people put extensions > wherever they feel like putting them (they will anyhow), remembering > that human-readability is a virtue. If models try to micro-manage > the element/attribute thing, those models are broken, don't use > them. > If software arbitrarily discards markup because the markup > doesn't match its idiosyncratic ideas about elements and attributes, > that software is non-comformant and non-interoperable. I'm a bit surprised that you're saying this. I'm not sure why you think it is non-conformant to discard extensions. RFC4287 doesn't describe any conformance criteria for Atom intermediaries. Over on atom-protocol, there were a number of implementors who are ignoring/rewriting client-supplied atom:ids - about the most fundamental way that you could possibly change an atom document - and you didn't seem to disapprove of this? People have also said in the past that they planned not to preserve extensions, and I don't remember there being many objections. If it is non-conformant and non-interoperable to discard extensions, then why doesn't APP prohibit it? >> Extension elements are defined to have both a model and a syntax, but >> Atom's allowance for foreign attributes to appear anywhere is a case >> of syntax that has no corresponding model. Atom doesn't really explain >> what foreign attributes are intended for. > Extension elements also, as noted above, have *no normative effect*. I don't know what "no normative effect" means. > This is only true for software which ignores the fact that RFC4287 is > specified only in terms of the XML Infoset. If you lose information > because it doesn't match up with some ex post facto model you've > dreamed up, you cannot expect to achieve interoperability. But every implementor is dreaming up ex post facto models. > Obviously, but the notion that this depends on whether you use an > attribute or an element seems really, really bizarre to me. An > intermediary that drops markup it doesn't recognize won't last long > in the marketplace, whether those are elements or attributes. It is easier to support extensibility in 3 places, than on every possible element in the document. Storing entry extensions in a database table is possible, storing atom:updated attributes, is getting silly. >> Interoperability should take priority of concerns that 'approach X >> looks >> better than Y', and other unjustifiable minor concerns. > Yes, and interoperability is based on the normative rules in RFC4287, > right? Wrong (in my opinion). There are no normative rules for the behaviour of Atom intermediaries. Given the absence of such rules, the next best way to ensure interoperability to understand the typical behaviour of Atom implementations: the fact that it is easier for some implementations to support "Extension Elements" in the 3 defined extension points than foreign attributes on every element in an Atom document; that this translates to more implementations supporting extension elements than attributes; and that this implies that an extension would be more interoperable if it chooses Section 6.4 markup over undefined foreign markup. -- Dave
