This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Creating the canonical XML for the reference result (as described in the guidelines) of query Expressions/Construct/DirectConElem/DirectConElemContent/Constr-cont-nsmode-1 raises an error because the content of the namespace attributes inherit or preserve (i.e. xmlns:inherit or xmlns:preserve resp.) is not an absolute URI. This affects also reference results of other queries, e.g. Constr-cont-nsmode-2, Constr-cont-nsmode-3, or copynamespace-2.
I'm moving this bug to the XQuery Test Suite.
I've made the URIs in these test cases absolute URIs, as you requested. Please mark this bug as closed if you agree with this resolution.
Created attachment 691 [details] List of files that I'm not able to bring into canonical xml
I scanned the complete testsuite and I think I discovered more problems of this kind. The attached file contains a list of files that also cause problems.
The expected test results for Constr-cont-nsmode-1 have not been fully corrected. The file currently reads <z xmlns:preserve="preserve" xmlns:inherit="http://www.example.com/inherit"/> and not <z xmlns:preserve="http://www.example.com/preserve" xmlns:inherit="http://www.example.com/inherit"/>
I've changed the expected test result for Constr-cont-nsmode-1 in the way that you have indicated.
I've fixed test case ExpandedQNameConstructFunc018. The URI generated by the test case is now http://www.example.com/Folder00000000001 instead of Folder00000000001.
Of the test cases that you've identified, I believe that the following still need attention: K2-ComputeConAttr-59 K2-DirectConElemNamespace-59 K2-DirectConElemNamespace-60 K2-DirectConElemNamespace-75 K2-DirectConElemNamespace-76 K2-DirectConElem-47 Frans, perhaps you could look at these.
The expected results for Constr-cont-nsmode-1 appear to have fixed one namespace but not the other. I have now fixed the other.
I'm not so sure if this is the right thing to do, XQuery allows relative namespace URIs, e.g this is a valid query: <a xmlns="1"/> And we need to be able to verify those queries, and the current way of comparing results hence prevents us from doing what the suite is set out to. E.g, if we have no queries with relative URIs, we don't test what we're supposed to test, as far as I can tell. Or no? I'm tempted to change the guideline document to compare as per c14n, but without treating relative URIs as an error. Any thoughts?
I'm not sure if the problem is located somewhere else. What does it mean to have a relative URI in a namespace attribute (since this is not allowed in XML anyway)? I think that this might be an error in the XQuery serialization specification. In the serialization process, any relative namespace attribute should be resolved against the static context's base uri. As a result, no (valid) XML should contain relative namespace attributes anymore. What do you think?
>What does it mean to have a relative URI in a namespace attribute (since this is not allowed in XML anyway)? Under the famous ruling of 11 Sept 2000, after fierce debate, they were deemed legal in XML but deprecated, and it was stated that later specifications such as XPath and DOM (and presumably XQuery by implication) "would define no meaning for them". So the answer to your question, according to Dan Connolly, is that you can use it but it means nothing. http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html [Not that an absolute URI means anything either.] A few products and specifications such as Canonicalization and XOM have gone further and reject relative URIs. This strengthens the case for avoiding them. In fact the status of relative URIs as namespaces is not all that different from "wannabe URIs", strings that are not valid URIs according to the RFC because, perhaps, they contain non-ASCII characters. The namespaces Rec goes out of its way to avoid saying that parsers must test namespace names against the URI spec and reject documents if the namespace name is not a valid URI. Which, in some people's eyes, means that every string is a legal namespace name (or at any rate, any string which can be produced as the result of attribute value normalization of a CDATA attribute). The XQuery spec similarly says that products may reject such strings but are not required to do so. In my view there are dragons here which the collective minds of W3C have failed to slay, and there is very little to be gained by having the XQuery test suite step out boldly into the quagmire. Commercial products usually implement many specifications in a single product, and where the specifications exhibit minor incompatibilities, they sometimes have to paper over the cracks in the interests of users. Many products, for example, allow the Sun-defined jar: "URI" format in interfaces where URIs are expected, even though these are not actually legal URIs, because it is a convenience to users and an aid to interoperability to permit them. I do not think anyone's interests would be well served if the XQuery test suite took it upon itself to award black marks to vendors who made this decision. For the same reason, I think the XQuery test suite should neither condone nor condemn products supporting relative URIs as namespaces - given the unclear W3C ruling, it's a difficult decision that vendors have to make and there is no right answer. >In the serialization process, any relative namespace attribute should be resolved against the static context's base uri. That is almost certainly something that you should most definitely NOT do. The fierce 2000 debate and its resolution made that very clear.
*** Bug 7975 has been marked as a duplicate of this bug. ***
Committed a slew of fixes related to this. Feel free to report back what still is missing. I believe the implementation erroneously reported on K2-DirectConElem-47, afaik the URIs shouldn't be subject to URI escaping. Closing as fixed, tentatively.
Since the bug report was opened 4 more tests with the same problem have been added: DirectConElemNamespace-3 DirectConElemNamespace-4 DirectConElemNamespace-5 DirectConElemNamespace-6 Otherwise I am happy that all the other tests are fixed correctly.
Some monitoring reveals the following tests that use invalid or relative URIs as namespace names, so the problem is more widespread than stated in comment #15: Test K2-DirectConElem-47 **** illegal URI used as namespace: http://example.com/<>"'" Test Constr-attr-nsdecl-1 **** relative URI used as namespace: uri Test K2-DirectConElemNamespace-59 **** illegal URI used as namespace: http://example.com/{{{}}}asd Test K2-DirectConElemNamespace-60 *** (Canonical XML:) namespace http://example.com/{{{}}}asd is not a valid URI Test K2-DirectConElemNamespace-65 **** illegal URI used as namespace: http://example.com/{}{{}} Test K2-DirectConElemNamespace-75 **** illegal URI used as namespace: http://example.com/{1} Test K2-DirectConElemNamespace-79 **** relative URI used as namespace: URL1 **** relative URI used as namespace: URL2 Test DirectConElemNamespace-3 **** illegal URI used as namespace: """asd Test DirectConElemNamespace-4 **** illegal URI used as namespace: "asd Test DirectConElemNamespace-5 **** relative URI used as namespace: ''''''asd Test DirectConElemNamespace-6 **** relative URI used as namespace: ''asd Test copynamespace-3 **** relative URI used as namespace: www.existingnamespace.com **** relative URI used as namespace: www.mynamespace.com Test copynamespace-14 **** relative URI used as namespace: www.another.com Test copynamespace-15 **** relative URI used as namespace: www.namespace1.com **** relative URI used as namespace: www.namespace2.com **** relative URI used as namespace: www.namespace3.com Test K2-InScopePrefixesFunc-6 **** relative URI used as namespace: asd Test K2-InScopePrefixesFunc-30 **** relative URI used as namespace: foo Test functx-functx-namespaces-in-use-1 **** relative URI used as namespace: abc **** relative URI used as namespace: def **** relative URI used as namespace: ghi **** relative URI used as namespace: xyz Test functx-functx-name-test-1 **** relative URI used as namespace: ns1 I shall fix some of these where the use of an unvalid or relative namespace is not germane to the test. Where the invalid or relative namespace is used deliberately and is of the essence of the test, I shall review the expected results to see whether they appear to be correct. For some tests, the problem arises only because of the use of canonicalization for comparing results. It may be possible to avoid this problem by comparing results as part of the test, using deep-equal.
I have attempted to fix this bug as follows: (a) For all tests in the tests suite that were using relative namespace URIs, I have changed the test to use an absolute URI instead. (b) For tests that were using an invalid URI as a namespace name, where this was not necessary for the purpose of the test, I have changed the test to use a valid absolute URI. (c) For tests that were using invalid namespace URIs by design, I have changed the test so that (i) the invalid namespace URI does not appear in the test output in a form that will cause canonicalization to fail, and (ii) XQST0046 is given as a possible test result, allowing for the fact that XQuery processors are permitted (but not required) to raise an error if an invalid URI is used as a namespace name. Note that this affects some tests that were not listed in the previous comment, because the monitoring only reported the first use of each illegal/relative URI.
The compare mode is still set to XML for the results of K2-DirectConElemNamespace-59, 60 and 75. Now that these tests have been rewritten the compare mode should be changed to text.
Fixed as suggested
Apologies for reopening this again, but the tests K2-DirectConElemNamespace-59, 60 and 75 are still not quite right There seems to be an extra newline character at the end of the expected results for these tests.
I've removed the offending newlines. However, I'm surprised you should be treating trailing newlines as significant.
Thanks for fixing this. I am somewhat confused by your comment though. According to the "Guidelines for running the XML Query Test Suite" (Comparing results): XML: The test harness must canonicalize both, the actual result and the expected result according to the Canonical XML recommendation [2], which refers to a number of open-source implementations. Byte-comparison can then be applied to the resulting XML documents. If the test harness does this process in a different manner, it must be documented. XML fragment: For XML fragments, the same root node must be created for both, implementation result and test suite result. The resulting XML can be compared using XML comparison. Text: Same comparison as "XML fragment". I assume that by "root node" it means "top level element" and so this would be equivalent to comparing <result>http://example.com/{{{}}}asd</result> to <result>http://example.com/{{{}}}asd </result> which are clearly different documents. Am I missing something here?
You seem to be right. Another fine mess. "Text" and "XML Fragment" shouldn't be the same - there were good reasons for them to be different - but one or the other was misused in the past and the documentation was changed to immortalize the error, leading to this kind of problem.
Some more tests were changed as a result of this bug: DirectConElemNamespace-3 DirectConElemNamespace-4 DirectConElemNamespace-5 DirectConElemNamespace-6 These tests still have compare mode set to XML, and so fail to canonicalize as there is text at the top level.
The change to DirectConElemNamespace-6 introduced one more problem. The query now looks like this: namespace-uri(<e xmlns:p='http://ns.example.com/ns?val=''asd'/>) The namespace of the element here is "", not "http://ns.example.com/ns?val='asd" as the test expects. I assume that either the element name should be p:e, or the namespace declaration should be for the default namespace.
I have fixed the problems identified in comments #24 and #25 as suggested.
Thanks. The only outstanding problem is the XQueryX version of the test, but that should sort itself out when the XQueryX tests are rebuilt. I am happy with all these fixes, but I will leave it to the original commenter to mark this bug closed.
I have added XQST0022 as an alternate result for tests: K2-DirectConElem-47 K2-DirectConElemNamespace-59 K2-DirectConElemNamespace-65 K2-DirectConElemNamespace-75 K2-DirectConElemNamespace-76 because, as it was also mentioned by a comment for these tests, some processors MAY report the URI's as invalid.
Re the previous comment, see Bug 13966.