> 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 KayReceived on Thursday, 23 October 2003 09:24:31 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:43 UTC