> > Thank you for your reply. It's interesting that until XPath 3.0, we could > *construct* empty-namespace elements inside non-empty namespace elements (via > the xmlns="" declaration), but we couldn't *query* them without resorting to > the somewhat means of indirect wildcards (e.g., `/*:elem`) or use of the > local-name function (e.g., `/*[local-name() eq 'elem']`). Is that right?
Yes, that's correct. XSLT 1.0 had similar problems and the xpath-default-namespace attribute was introduced in 2.0, but I remember failing to persuade the XQuery WG that XQ needed something similar. The WG as a whole was quite resentful of the amount of complexity that namespaces brought to the language, and wanted to avoid adding more and more complications. I had shared some of that frustration when first developing Saxon: I recall complaining on one occasion that the product would be about 30% smaller if it weren't for namespaces. I remain convinced that namespaces, in the form that XML defined them, were a major design mistake. (I'm sure I posted to xml-dev, though I have failed to find the post subsequently, that it didn't really matter, because the design of namespaces was so bad that no-one would ever use them.) What exactly are the problems with the design? * A compound name (uri+local) adds complexity to every API that involves passing names, when compared with using a single string. * The use of namespace prefixes creates ambiguity as to whether the choice of prefix is significant or not. (If it weren't for QNames-in-content, we could say that prefixes aren't significant and can be dropped; but even then, as with CDATA sections etc, some people would want the parser to preserve them). * The use of prefixes makes APIs for constructing XML a lot more complex. * Declaring namespaces using attributes, rather than through some separate syntactic construct, creates messiness in the data model and conceptual confusion. I think all the goals of XML namespaces could have been achieved with a much simpler design. For example: * Element and attribute names are simple strings, typically in the form <org.w3.xslt:transform> (let's call the "org.w3.xslt" part a qualifier) * Using an explicit qualifier in an element name establishes a default qualifier for child elements. * Omitting a qualifier is a simple input abbreviation and doesn't affect the element name notified to applications by the parser * Attribute names, if they need a qualifier, are always written in full, e.g. org.w3.xml:base. XSLT is one of very few vocabularies where elements in different namespaces are freely mixed; it's also one of very few that uses namespace prefixes in content (i.e. not in element or attribute names). The design of XML namespaces was possibly over-influenced by this unusual use case. XSLT could have handled it differently, e.g. with a rule that elements starting X: are XSLT instructions, where X defaults to "xsl" but can be user-declared. In nearly all other cases where multiple namespaces are used, there is an element (such as svg:svg or soap:body) that signals a namespace switch which applies to the entire subtree of that element, and a design that optimized for that use case would have been better. > > I'd be interested to know more about the history of the development of > namespaces and efforts to bridge the world of namespaces (namespace > axis-land) with the world of documents without this axis (namespace > flat-land). Is there any good published account of this? > No, millions of words have been written on the subject on xml-dev, but there is no succinct summary of the history. What is undoubtedly true is that the design was rushed through without enough thought or consensus. I found myself in the odd position in the XQuery WG of being the person who was always pushing the James Clark model of namespaces, e.g. the way namespace nodes work, and this probably meant people thought I was an enthusiast for namespaces whereas I actually thought simply that the Clark model was the best way of limiting the damage. XQuery 3.0 got itself into the strange position of finding that it needed namespace nodes to achieve completeness on the document construction side of the language, but still rejected use of namespace nodes and the namespace axis on the retrieval side. I always found that pretty weird. Michael Kay Saxonica
_______________________________________________ talk@x-query.com http://x-query.com/mailman/listinfo/talk
