"Danny Sokolsky" <dsokol...@marklogic.com> writes: > The xmlns "attribute" is not exactly an attribute, and for some > obscure/arcane XML and XQuery specification reasons that I cannot > adequately explain here, you are not allowed to use an attribute > constructor to construct the special xmlns "attribute" and have that > value be your default namespace for the constructed element. I think > (not sure here) the reason has something to do with the element > constructor specifying a QName for the element, and that QName cannot be > changed later on in the constructor.
The *original* XML Recommendation[1], from 1998, only hints at the notion of namespaces: Note: The colon character within XML names is reserved for experimentation with name spaces. Its meaning is expected to be standardized at some future point, at which point those documents using the colon for experimental purposes may need to be updated. Namespaces were invented later and are defined separately. When the time came to decide how to integrate XML Namespaces into the syntax of XML, it was too late to change XML. Several proposals were considred. The one ultimately selected was to (ab)use the attribute production in XML to insert pseudo-attribute namespace declarations. The fact that several different APIs evolved during the interregnum between "XML without namespaces" and "XML with namespaces" only served to muddy the waters further. In some APIs, these pseudo-attribute namespace declarations *are* treated as attributes and in some they aren't. It's unfortunate, but it's true. However, from the point of view of modern languages and APIs built on the foundation of XML with namespaces (i.e. XPath, XSLT, XQuery, XProc, etc.), namespace declarations *are not attributes*. The fact that they appear, syntactically to be attributes when you're looking at the serialized form of an XML document is simple an historical artifact. So the short answer to the question "why can't I use an attribute constructor to create them" is "because they aren't attributes." The longer answer is a little more complicated. Not only do the declarations have a misleading appearance, after you've parsed the document, you don't need them at all (this isn't strictly true because of the "QNames in content problem"[2], but let's ignore that for the moment). They exist "merely" to tell the parser how to interpret names with colons. After the parser has seen <p:x xmlns:p="http://example.org/ns"/> It knows that the element has the name "x" in the namespace "http://example.org/ns";. At this point, that declaration isn't needed anymore. Conversely, when you're constructing an element, you tell the processor what QName to use, e.g. element { QName("http://example.org/ns","y";) } { ... } If you were allowed to add "xmlns" attributes to the element, then at best, you'd introduce changes to the data model that would require the processor to "look backward" and perform fixup. At worst, you'd introduce unresolvable conflicts into the data model. I hope that helps... Be seeing you, norm [1] http://www.w3.org/TR/1998/REC-xml-19980210 [2] http://www.w3.org/2001/tag/doc/qnameids -- Norman Walsh Principal Technologist Mark Logic Corporation _______________________________________________ General mailing list General@developer.marklogic.com http://xqzone.com/mailman/listinfo/general
