Re: namespace node implementation

Kay, Michael wrote:

> I haven't yet implemented the new construction rules: when you add an 
> element to a new parent in Saxon today, it will inherit the namespaces 
> of its new parent, which is incorrect according to the spec.

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

Xavier Franc wrote:
 > - when copying an existing node into a constructed tree, there is a
 > choice about copying in-scope prefix/ns mappings:
 >     1- copy all in-scope mappings: ...
 >     2- copy only mappings defined on the node itself: more concise
 >     3- copy no mappings at all: wont result in nice serialization
 >     4- copy only if used in sub-tree: best but not efficient

My proposal is a variant of (1).  I would copy all the in-scope mappings 
from the source (just a pointer copy), but the result is not merged with 
the namespaces in the target, since I don't search up the parents for 
get-in-scope-namespaces.  Of course when serializing you get namespace 
inheritance, so you get a merged namespace mapping when you read the 
serializaing document back in again.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Wednesday, 22 October 2003 14:22:25 UTC