RE: namespace node implementation

> 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.

  It could be:
> 
> ("ns2"):  Problematical.  The "ns1" prefix isn't available for 
> serializing the ns1:x attribute, so the processor either has 
> to make up 
> a new prefix (which is a poor interface), or has to search 
> some global 
> table of "namespace prefixes we've used" (unreliable).
> ("ns1", "ns2"):  Works but requires merging or copying, which is 
> difficult to do efficiently.  (It could be a high-frequency 
> operation.)
> ("ns1"):  Works.  Simple.  Supports user-expected serialization. 
> Efficient to implement using my proposal.  I think it is 
> compatible with 
> the requirements in section 3.7.4 of the August draft, but I could be 
> missing something.

Yes, I think that "ns1" is the right answer. (And of course, it also has a
namespace node for the XML namespace).

The tricky thing is that when you come to serialize, the XML 1.0
serialization is

<c xmlns:ns2="NS2"><b xmlns:ns1="NS1" ns1:x="X"/></c>

but the more accurate XML 1.1 serialization is:

<c xmlns:ns2="NS2"><b xmlns:ns2="" xmlns:ns1="NS1" ns1:x="X"/></c>

In the serialization spec we have a parameter
undeclare-namespaces="yes"|"no" to control this.


Michael Kay