Cart
|
[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)
 At 01:17 PM 3/30/01 +0800, Rick Jelliffe wrote: >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. Huh? The order of elements is preserved, and I haven't seen much embrace-and-extend that I would consider harmful... >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. "Because no one has questioned the imposition of a processing model on the syntax previously, we shouldn't take this question seriously." Okay. >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. Is that a problem with those applications, or is that a problem with the original processing model? By losing the ordering information, the model leaves itself open to embrace-and-extend in a manner which would not have been an issue had the ordering information been preserved. >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. In case it isn't obvious, I rather seriously doubt how useful the infoset is at this point. I'm more or less suggesting that the imposition of infoset understandings on the syntax is shutting off some useful possbilities while leaving other complexities unanswered. >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.) Does that history mean that attributes should/must always be treated as unordered? There's reuse and there's adaptive reuse. Simon St.Laurent - Associate Editor, O'Reilly and Associates XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books 
|
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
|
|||||||||
