namespaces and the doc() function: conflicting prefix bindings persist past their scope?
I'm having a puzzling experience with BaseX 7.6 running under Mac OS X 10.6.8. Consider the following document, in my file system as test.xml: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="back"/> <xsd:element name="body"> <xsd:annotation xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"/> </xsd:element> <xsd:element name="bold"/> </xsd:schema> The query doc('.../test.xml')//xs:element returns not three elements, but just the first two. The third element is encountered after the prefix 'xsd' was temporarily rebound to a different namespace, and it is not recognized as being in the same namespace as the other 'element' elements. (Further investigation shows that the system believes it to be in namespace http://www.w3.org/2000/10/XMLSchema.) Some observations: - The behavior has nothing to do with the specific namespace or the fact that the XSD namespace is predefined; analogous behavior occurs with the following document: <a:a xmlns:a="http://example.com/a"> <a:b/> <a:b> <x xmlns:a="http://example.com/x"/> </a:b> <a:b/> </a:a> - If a database is built using the document just given, the query declare namespace foo = "http://example.com/a"; //foo:b returns two elements, not three. In my tests, it appeared not to matter whether I checked or unchecked the 'Use internal XML parser' box; I got two elements either way. - The behavior changes if the document is given literally in the query; the following query returns three {http://example.com/a}b elements, not two: declare namespace foo = "http://example.com/a"; let $doc := <a:a xmlns:a="http://example.com/a"> <a:b/> <a:b> <x xmlns:a="http://example.com/x"/> </a:b> <a:b/> </a:a> return $doc//foo:b Is this a bug, or am I doing something wrong? It looks as if something were going wrong in the XML parser's management of namespace bindings. Thanks for any light you can shed on the matter. In the short run I suppose I can try to revise my XSLT to suppress the unnecessary namespace rebindings. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Dear Michael, thanks for your observations and your thorough report. I definitely agree this looks like a bug, which also occurs in the latest snapshot, and I am even more surprised this has not been observed earlier. I have added a bug report to GitHub [1], and we will give you notice whenever this has been fixed. All the best, Christian [1] https://github.com/BaseXdb/basex/issues/697 ___________________________ On Fri, May 10, 2013 at 4:06 AM, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
I'm having a puzzling experience with BaseX 7.6 running under Mac OS X 10.6.8.
Consider the following document, in my file system as test.xml:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="back"/> <xsd:element name="body"> <xsd:annotation xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"/> </xsd:element> <xsd:element name="bold"/> </xsd:schema>
The query doc('.../test.xml')//xs:element returns not three elements, but just the first two. The third element is encountered after the prefix 'xsd' was temporarily rebound to a different namespace, and it is not recognized as being in the same namespace as the other 'element' elements. (Further investigation shows that the system believes it to be in namespace http://www.w3.org/2000/10/XMLSchema.)
Some observations:
- The behavior has nothing to do with the specific namespace or the fact that the XSD namespace is predefined; analogous behavior occurs with the following document:
<a:a xmlns:a="http://example.com/a"> <a:b/> <a:b> <x xmlns:a="http://example.com/x"/> </a:b> <a:b/> </a:a>
- If a database is built using the document just given, the query
declare namespace foo = "http://example.com/a"; //foo:b
returns two elements, not three. In my tests, it appeared not to matter whether I checked or unchecked the 'Use internal XML parser' box; I got two elements either way.
- The behavior changes if the document is given literally in the query; the following query returns three {http://example.com/a}b elements, not two:
declare namespace foo = "http://example.com/a"; let $doc := <a:a xmlns:a="http://example.com/a"> <a:b/> <a:b> <x xmlns:a="http://example.com/x"/> </a:b> <a:b/> </a:a> return $doc//foo:b
Is this a bug, or am I doing something wrong? It looks as if something were going wrong in the XML parser's management of namespace bindings.
Thanks for any light you can shed on the matter. In the short run I suppose I can try to revise my XSLT to suppress the unnecessary namespace rebindings.
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Puzzling should be over now; we have found and fixed the tricky bug and I have uploaded a new snapshot [1]. Hope this helps, Christian [1] http://files.basex.org/releases/latest/ ___________________________ On Fri, May 10, 2013 at 4:06 AM, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
I'm having a puzzling experience with BaseX 7.6 running under Mac OS X 10.6.8.
Consider the following document, in my file system as test.xml:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="back"/> <xsd:element name="body"> <xsd:annotation xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"/> </xsd:element> <xsd:element name="bold"/> </xsd:schema>
The query doc('.../test.xml')//xs:element returns not three elements, but just the first two. The third element is encountered after the prefix 'xsd' was temporarily rebound to a different namespace, and it is not recognized as being in the same namespace as the other 'element' elements. (Further investigation shows that the system believes it to be in namespace http://www.w3.org/2000/10/XMLSchema.)
Some observations:
- The behavior has nothing to do with the specific namespace or the fact that the XSD namespace is predefined; analogous behavior occurs with the following document:
<a:a xmlns:a="http://example.com/a"> <a:b/> <a:b> <x xmlns:a="http://example.com/x"/> </a:b> <a:b/> </a:a>
- If a database is built using the document just given, the query
declare namespace foo = "http://example.com/a"; //foo:b
returns two elements, not three. In my tests, it appeared not to matter whether I checked or unchecked the 'Use internal XML parser' box; I got two elements either way.
- The behavior changes if the document is given literally in the query; the following query returns three {http://example.com/a}b elements, not two:
declare namespace foo = "http://example.com/a"; let $doc := <a:a xmlns:a="http://example.com/a"> <a:b/> <a:b> <x xmlns:a="http://example.com/x"/> </a:b> <a:b/> </a:a> return $doc//foo:b
Is this a bug, or am I doing something wrong? It looks as if something were going wrong in the XML parser's management of namespace bindings.
Thanks for any light you can shed on the matter. In the short run I suppose I can try to revise my XSLT to suppress the unnecessary namespace rebindings.
-- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
On May 29, 2013, at 8:13 AM, Christian Grün wrote:
Puzzling should be over now; we have found and fixed the tricky bug and I have uploaded a new snapshot [1].
Thank you! -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
participants (2)
-
C. M. Sperberg-McQueen -
Christian Grün