[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: attribute order (RE: Syntax Sugar and XML information models)
From: Simon St.Laurent <simonstl@s...> >I'm not really sure what good it does to specify that order is discarded >entirely, though at least I suspect it does less harm than claiming that >all namespace prefix information should be discarded entirely. Because then some company or renegade would doubtless use it for embrace-and- extend in some unimaginable way. At the moment it is clear that attribute order is not something that anyone should used in decisions on processing attributes or elements, and no-one seriously doubts that or does any different. Changing this would be a classic embrace-and-extend manouver: we would be able to produce conforming XML which had some kind of information that other systems could not detect. For example, if some scary and enormous corporation with such a bad track record no-one can believe a word it says anymore or its leading competitor decided that <pants husband="jim" wife="jean" /> and <pants wife="jean" husband="jim" /> meant that the first attribute indicated who wore the pants, then current DOM based systems (or XPath based systems) would not see any difference. Now, this is not to say that a system could not, for process-internal an non-exported data, order the attributes as a way to implement some useful function (e.g. c14n testing, or that the first position in the attribute array is the ID if any exists to allow fixed-index lookups, or that invalid attributes go to the end, or that attributs are ordered by namespace to allow searching, etc.) but that is very different from the order being significant at the infoset level. I would say there is another reason why attributes should be unordered. Goldfarb's SGML Handbook has a potted history. The difference between the 70s style gencoding and the 80s innovation of generalized markup is the introduction of attributes to subclass the element: the genus of the element is specified in the "generic identifier" and the species is identified through the use of attributes. (Attribute syntax being available, they are then appropriate for IDs and IDREFs and other links too, but these are not "generalized markup" per se, it seems.) So the attributes are a bag not a set. I think I have pointed out before that this is one current short-coming ("simplification", Lord spare us) of XML Schemas: that it does not actually provide any support for generalized markup in the above sense. You will notice if you read through the drafts (I believe this is not the entertainment of the future) that the <restriction> element was at first an attribute: it had to be changed to elements because, not supporting generalized markup, there was no way to get acceptable strong-typing when an attribute changes the content model. Cheers Rick Jelliffe Cheers Rick Jelliffe
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|