This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The test suite does not currently test the copy-namespaces declaration in a way that is usable with an XML Namespaces 1.0 system. The no-inherit flag which is set in tests 1 and 3 does stop the nested b element aquiring a namespace binding for p.uri inherited from the parent p element, but as the result includes p as well as b an XMLNS 1.0 processor can not serialise the lack of binding on the child, and so results 1 and 3 (and 2 and 4) will be identical. I noticed this as my own system passed all these tests despite it not implementing no-inherit at all! Furthermore some of the tests have multiple allowed results, not all of which seem to be justified. For example Constr-cont-nsmode-1.xml loses the z2.uri binding on the element <b> which does not seem to be justified given that preserve and inherit are both set. (The alternative result Constr-cont-nsmode-1b.xml is what I would expect.) An alternative test that does show the inscope namespaces that are (or are not) on children without relying on XMLNS 1.1 undeclarations would be declare copy-namespaces no-preserve,no-inherit; declare variable $x := <x xmlns:preserve="preserve"><z/></x>; declare variable $y := <y xmlns:inherit="inherit">{$x}</y>; for $n in in-scope-prefixes($y/x/z) order by $n return $n (with the four possible settings of copy-namespaces) This does produce four unique results that are not system dependent, apart from the xml declaration,, as shown for example by saxon: $ for i in nsmode[1-4].xq; do echo "";saxon8q $i;done <?xml version="1.0" encoding="UTF-8"?>xml <?xml version="1.0" encoding="UTF-8"?>preserve xml <?xml version="1.0" encoding="UTF-8"?>inherit xml <?xml version="1.0" encoding="UTF-8"?>inherit preserve xml
This bug might have been fixed through #5250, will wait for next release. Note that we cannot use the in-scope-prefixes function as it is not part of the foundation set.
(In reply to comment #1) > This bug might have been fixed through #5250, will wait for next release. > Note that we cannot use the in-scope-prefixes function as it is not part > of the foundation set. 5250? there doesn't appear to be a bugzilla entry with that number, so what's this refering to? It is presumably within the power of the WG to add in-scope-prefixes() to the functions allowed in test files. Without that, and without the namespace axis, it's hard to test copy namespaces adequately I would have thought. Especially as this feature is flagged as at risk it seems more important to test the feature fully than to keep to some subset of the core function library which means that you are trying to test namespace support without using the only functions that give you access to namespace information. David (somewhat confused by your reply:-) Having said that, in-scope-namespaces function isn't really essential for the particular test I suggested in this report, you can just return the node, as shown below. declare copy-namespaces preserve,inherit; declare variable $x := <x xmlns:preserve="preserve"><z/></x>; declare variable $y := <y xmlns:inherit="inherit">{$x}</y>; $y/x/z With again the four possible settings of copy-namespaces returns four different results in saon (and xq2xsl) $ for i in test[1-4].xq; do echo "";grep copy $i;saxon8q $i \!omit-xml-declaraion=yes ;done declare copy-namespaces no-preserve,no-inherit; <z/> declare copy-namespaces no-preserve,inherit; <z xmlns:inherit="inherit"/> declare copy-namespaces preserve,no-inherit; <z xmlns:preserve="preserve"/> declare copy-namespaces preserve,inherit; <z xmlns:preserve="preserve" xmlns:inherit="inherit"/>
It's bug 2520, I think there are no more overloaded namespaces in the latest results.
The problem is still there in 0.8.2, see the run with saxon below. the tests test the preserve/no-preserve switch but they do not test inherit/no-inherit. The only difference between inherit and no-inherit is whether the p.uri binding from the direct element constructor produces a binding for that namespace on the child elements. However since the result includes the parent p element, it is impossible to see (using a namespaces 1.0 serialisation) whether the namespace binding is in scope on the children as the serialised form always makes bindings in scope to all children. So the result of test 1 will be the same as test 3 and the result of test 2 will be the same as test 4. Saxon agrees with this analysis, as seen below (note no output from diff in the first two comparisons) In order to test inherit using xml namespaces 1.0 you need to output the child _without_ outputting the parent from which the namespace was inherited (eg the test I suggested in comment #2) $ saxon8q Queries/XQuery/Expressions/Construct/DirectConElem/DirectConElemContent/Constr-cont-nsmode-1.xq +input-context=TestSources/nsmode.xml >1.xml $ saxon8q Queries/XQuery/Expressions/Construct/DirectConElem/DirectConElemContent/Constr-cont-nsmode-2.xq +input-context=TestSources/nsmode.xml >2.xml $ saxon8q Queries/XQuery/Expressions/Construct/DirectConElem/DirectConElemContent/Constr-cont-nsmode-3.xq +input-context=TestSources/nsmode.xml >3.xml $ saxon8q Queries/XQuery/Expressions/Construct/DirectConElem/DirectConElemContent/Constr-cont-nsmode-4.xq +input-context=TestSources/nsmode.xml >4.xml $ diff 2.xml 4.xml $ diff 1.xml 3.xml $ diff 1.xml 4.xml 3,4c3,4 < <z:a xmlns:z="http://www.example.com/z.uri" xmlns:p="http://www.example.com/p2.uri"> < <b xmlns:y="http://www.example.com/y.uri" xmlns:z="http://www.example.com/z2.uri"/> --- > <z:a xmlns:z="http://www.example.com/z.uri"> > <b/>
I changed the tests to the ones suggested on 12-03.