RE: namespace node implementation

> I don't understand this:
> (from M. Kay's message 
> http://lists.w3.org/Archives/Public/www-ql/2003OctDec/0043.html)
> 
> >> Right, and that's the problem I'm concerned about (assuming we're 
> >> talking about the same thing).  Given:
> >>
> >> let $a := <a xmlns:ns1="NS1"><b ns1:x="X"/></a>
> >> let $c := <c xmlsns:ns2="NS2">{$a/b}</c>
> >>
> >> what is the result of get-in-scope-namespaces($c/b)?
> >
> > When <b> is constructed it acquires a namespace node for 
> ns1 by virtue 
> > of the fact that ns1 is an active in-scope namespace at that point.
> >
> > When <a> is constructed it also acquires a namespace node 
> for ns1 for 
> > the same reason.
> >
> > When <b> is copied to make it a child of <a> it retains (copies of) 
> > its namespace nodes.
> >
> > The path expression $a/b selects this b element. The 
> element is copied 
> > to make it a child of the new <c> element. It retains the ns1 
> > namespace node, but does not acquire a namesapce node for ns2.
> >
> ...
> > but the more accurate XML 1.1 serialization is:
> >  <c xmlns:ns2="NS2"><b xmlns:ns2="" xmlns:ns1="NS1" ns1:x="X"/></c>
> 
> 
> What is the meaning of "[it] does not acquire a namesapce 
> node for ns2." ? First, what is "it" ? the first node $a/b or 
> the new node $c/b ? (I assume it is the latter)

Yes, the latter.
> 
> Why should the new node ($c/b) _not_ have NS2 in its 
> "in-scope namespaces" ? 

Well, the design could have gone either way. We decided on this design
because

(a) with the XML 1.1 model, it is not necessary for a child element to
inherit all the namespaces of its parent

(b) in general, inheriting the namespaces of the parent doesn't achieve
anything useful. If the subtree rooted at A uses a particular namespace,
then it will already have that namespace in scope; when A becomes a child of
B, it will never actually need the namespaces that are available on B.

(c) inheriting the namespaces of the parent can be a nuisance. The canonical
example is when you attach a payload XML document to a SOAP envelope, and
later detach it again, you find that the payload has acquired all the SOAP
namespaces.

(d) some implementors appear to believe that the greater the number of
namespaces are attached to an element node, the greater the performance
overhead.


[BTW the definition of "in-scope 
> namespaces" is far from clear.]

The term is defined in the InfoSet, and essentially means the same as "the
set of namespace nodes for an element". I prefer the latter term, which uses
the terminology of our data model rather than someone else's.

> 
> I don't see in the spec something that would prescribe such a 
> strange rule: could you please Michael point it out ? The 
> argument "serialization should roundtrip" seems not 
> sufficient, because what matters is that element and 
> attribute names get their proper NS, and there are different 
> ways to serialize to get this result.
> 

The rule that nodes don't acquire extra namespace nodes when attached to a
parent is in 3.7.1.3, but it's there by omission. It says (in 1d) "For each
node returned by an enclosed expression, a new deep copy of the node is
constructed, including all its children, attributes, and namespace nodes (if
any)". It doesn't say that you create new namespace nodes corresponding to
those on the parent element, and therefore you don't. 

Michael Kay