[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Errors in Kendall Clark's xml.com article on QNames
On Wed, 2002-02-13 at 08:50, Henry S. Thompson wrote: > 1) "Consequently, all scope information, i.e. exactly where every > xmlns declaration is and what prefix it uses, must always be passed > to the application, regardless of whether it's needed or not..." > (quoting Evan Lenz [2], ellipses in original) > > This is wrong on two counts. The Infoset REC clearly defines what > _is_ required for applications that need it, namely the [in-scope > namespaces] property, which is much simpler than "where every xmlns > declaration is and what prefix it uses". That "feature" was added to the Infoset precisely because QNames were receiving use in attribute values at the W3C. Is it simpler? In some ways. Does it mean keeping extra scope information around? Definitely. It still qualifies as a burden to application developers. > Furthermore, and more to > the general layering and modularity point at issue, the Infoset REC is > designed specifically to provide applications with a vocabulary for > stating what they require from a parser. If an application doesn't > use QNames in values, it can define its profile of required Infoset > items and properties to not include the [in-scope namespaces] property > and the *Namespace* information item. Such applications would then be > happy with parsers which don't provide this information. That's completely useless to those of us writing generic XML processing tools. I get to do a lot of extra work to support your (bogus, IMHO) use of QNames because my application may well feed into other applications. There's no easy escape from that requirement - except perhaps the naive approach many developers take of just processing based on QNames with fixed prefixes, and ignoring the URI connection completely. > 2) "..there's no way for an XML processor to tell whether QNames are > used in values." (again, quoting Lenz [2], ellipses in original) > > That's simply false -- any sensible use of QNames would involve a W3C > XML Schema or other type-assigning schema language, That's simply false. QNames were created by the Namespaces in XML specification, and are not necessarily an appropriate "type". They are a notation for identifying markup. Sensible use of QNames would have respected the usage presented by Namespaces in XML and avoided creative and deeply complicating reuse. Calling something a "type" provides no help for those of us who see typing systems to be a complicating problem for markup rather than a simplifying solution. In this case I'd say the QName type is merely an excuse for and blessing of bad practice. I think I made that case back in March 2000, as Kendall notes. > which in turn > would identify all element content and/or attribute values which were > QNames. This means that using type-aware XPath 2.0 it would be > trivial to locate all QNames in a document. Note further that any > sensible API for type-information-bearing infosets will expose the > _values_ of leaf nodes, which for QNames is defined as being a pair of > namespace name and local name. And those of us who find type-aware XPath 2.0 to be a minefield of little value remain just as screwed as ever. > I must say I find this article, and the anti-QName sentiments it > quotes, quite bizarre. Why use two mechanisms to do the same thing, > namely establish ownership/semantic scope for names? XML Schema > should have erected an independent scoped mechanism for associating > URIs with local names? Can you _imagine_ the outraged howls of > "bloat, complexity, failure to learn from experience" etc. if we had > suggested such a thing? I must say I find the notion that defining types solves these kinds of problems - magically importing additional information from the surrounding document into an attribute value - to be extraordinarily bizarre. I don't yet see a PSVI API that performs this magic transparently, either. If you want to associate a URI and a local name, there's an easy way to do it: two attribute values. See, for instance, [1]. I thought it was already too late to fix this disaster in March 2000, and I still consider it too late. Justifying this approach or claiming that it doesn't exist seems to me a larger error than merely continuing bad practice, however. [1] - http://simonstl.com/projects/fragment/rules.xml -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com
|
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
|