Re: Namespace resolution in L3 Core and XPath (was Full infoset support for DOM 3 Core)

Curt Arnold wrote:

>Node.namespaceURI is pretty confusing, especially "This is not a computed
>value..."  If a node is created by loading an XML document and namespace
>processing was turned on, you would expect nodes to have a namespace URI
>based on its prefix even if the namespace binding is defined on an ancestor
>node which would require "computing" even though it would be handled
>typically by the SAX layer underneath.  However saying its value is null if
>the node was created by createElement or createElementNS(null,...) would
>probably get make the point that you were trying to make.  "namespace URI of
>this node" is also potentially confusing, since it might be interpreted as
>the namespace URI of the qualified name of this node (and a complement to
>localName) or as the default namespace.
>
Perhaps the wording could be more clear.  But the declaration of a 
namespace is clearly separate from the node that uses the prefix.  Let's 
clarify that this is pure level 2 stuff.  Node.namespaceURI is clearly 
not a computed value.  It is set when the node is created and never 
mutated thereafter.  Sure, a parser needs to compute the value when 
creating the node, just like it computes other things.  But it is not a 
dynamically computed value, as are others (such as the new baseURI in 
Level 3).  In level 2, when this was written, parser behaviors were not 
being described, and even now, parsing is only described in another 
module.  DOM core properly assumes that ultimately, these nodes are 
created using the constructors in core.   When the value is retrieved, 
DOM does not compute this value.  It uses the exact value specified when 
the Node was created.  To do anything else would be wrong.

>Node.localName: The note on createElement and other nodes is inconsistent
>with the behavior of XPath's local-name() which would return a local-name
>for unqualified tag names.   I would say that localName returns the same
>value as nodeName except for ELEMENT_NODE and ATTRIBUTE_NODE.
>localName(doc.createElement("foo")) should return the same value as
>localName(doc.createElementNS(null,"foo"))  Raising an exception or
>returning null on localName(doc.createElement("myns:foo")) would be
>appropriate.
>
The actual behavior is, again, established in level 2 and widely used 
and implemented.  Perhaps section 1.1.9 makes it clearer for you.  You 
should not choose createElement over createElementNS just because the 
particular element has no prefix or no namespaceURI.  A QName may have 
no prefix, and not all elements have namespaceURIs in a namespace-aware 
applicatiion.  You should never be using createElement if you anticipate 
using any namespaces or namespace-aware calls within your application. 
 More generally, as long as you can guarantee that you will execute 
under at least level 2 DOM, you should never use createElement or the 
other methods that were superceded in level 2 with namespace-aware 
equivalents.  If you cannot guarantee that you will execute on at least 
DOM level 2, then your application must use the old methods and never 
call the NS methods.  It is therefore irrelevant, even intentional, that 
elements created using this method have no localName -- because no 
program which asks for a localName should have ever called 
createElement, which exists for backwards compatibility.  After long 
analysis in level 2, it was declared impossible to get reliable results 
when intermixing use of the backwards-compatible methods with use of the 
level 2 NS-aware methods.  So you have to choose.

Ray Whitmer
rayw@netscape.com

Received on Thursday, 6 September 2001 20:09:23 UTC