This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
According to the guidelines for running XQTS: ''The "at" keyword specifies an optional location hint. Location Hints can be interpreted or disregarded in an implementation-dependent way. An implementation can choose to use any of the location hints, or none at all. Implementors testing a system that would only use one location hint may choose rewrite the query to use a URI to a system specific module (which has done the merge "by hand").'' A number of recently committed tests have used location hints for modules: modules-19 modules-20 modules-21 modules-22 modules-23 modules-24 modules-25 modules-26 modules-27 modules-28 and for schemas: fn-datacomplextype-1 fn-datamixedcontent-1 e.g. import module namespace defs = "http://www.w3.org/TestModules/defs" at "module3- lib.xq"; Use of ' at ' is testing implementation-defined behaviour. For instance, we attempt to use the location hint, fail to find the module and raise XQST0059.
I think we should probably reconsider how best to handle this. The current system of registering all modules in global entries in the catalog doesn't seem very scaleable. Probably the entry for each test case should say which library modules it uses, and give the mapping from the module URI to the actual location of the library module. Meanwhile I agree, the new tests are wrong.
validate-constraints-1, 2 and 3 need to be added to the list.
Also validate-constraints-1.
(In reply to comment #3) > Also validate-constraints-1. > Judging from your comment in bug #8708, I think you meant validate-constraints-4
I did.
I have removed the location hints from all these tests.
I believe the namespace in the catalog is also incorrect. It is currently: <module namespace="http://www.w3.org/TestModules/module1">module4-lib</module> but should be: <module namespace="http://www.w3.org/TestModules/defs">module4-lib</module>
Yes, the namespace should be <module namespace="http://www.w3.org/TestModules/defs">module4-lib</module>. I have corrected it, and I've also corrected a similar error with modules-recursive1.
Having updated from CVS, these tests appear to remain broken. validate-constraints-1 validate-constraints-2 validate-constraints-3 validate-constraints-4 There appears to be no <schema> element in the XQTSCatalog for constraints.xsd. modules-19 modules-20 modules-21 modules-23 modules-24 Expected runtime error(s): XQST0036, was XQST0059 Failed to import the module with target namespace 'http://www.w3.org/TestModules/defs'. The module was not found in the static context and no location hints were supplied. The <module> tags in <test-case> elements have namespace attributes which are not in accordance with the specified modules, i.e. <module namespace="http://www.w3.org/TestModules/module1">module3-lib</module> should be <module namespace="http://www.w3.org/TestModules/defs">module3-lib</module> modules-25 modules-26 modules-27 (Q:\XQTS-CVS/) Expected runtime error(s): XQST0081, was XQST0012 Type 'http://www.w3.org/2001/XMLSchema:untypedAtomic' is not declared, or is not a simple type. This is because XML Schema attribute.xsd uses xs:untypedAtomic, which is not defined in XML Schema. modules-28 (Q:\XQTS-CVS/) Expected runtime error(s): XQST0093, was XQST0059 Failed to import the module with target namespace 'http://www.w3.org/TestModules/defs2'. Import failed from xqts:///modules-recursive2.xq. modules-recursive2.xq uses a location hint.
Hi Tim, I've done my best to fix these tests according to your descriptions. Please test the fixes, and mark the bug as closed if you agree with my solutions. John
These issues have been fixed, but there are still some problems with the modules tests. Firstly, module3-lib and module4-lib still use a location hint to load the schema. modules-21 is as follows: import module namespace defs = "http://www.w3.org/TestModules/defs"; defs:function2(1 cast as simple:myType) It expects (non-existant) error XQST0081. I assume it should have been be XPST0081 (unbound prefix). However the imported module uses the schema with target namespace "http://www.w3.org/TestModules/defs" and so I believe that XQST0036 is also appropriate. This also applies to modules-23 and modules-24 The tests modules-25, modules-26 and modules-27 all import module4-lib.xq whose content is as follows: declare variable $defs:var as schema-attribute(sample:attrib) := attribute sample:attrib{ 1 }; declare function defs:function1() as schema-attribute(sample:attrib) { attribute sample:attrib{ 1 } }; declare function defs:function2($param as schema-attribute(sample:attrib)) as xs:integer { $param cast as xs:integer + 1 }; In several places in this module a newly constructed attribute (with type annotation xs:untypedAtomic) is used where a schema-attribute(sample:attrib) is expected. Thus I believe any test importing this module should also expect XPTY0004, which seems to undermine the test. The module could be fixed by validating the constructed attributes, although this doesn't seem to be possible in XQuery (why can we only validate elements?). The only way to fix this test is either to use the type schema-attribute(sample:attrib)? and the value (), or to expand the schema such that we can validate an element containing a sample:attrib attribute and then extract the attribute.
One more problem with these tests: validate-constraints-1 - 4 are all marked isXPath2="true" when they are not valid XPath 2 tests.
(In reply to comment #11) > Firstly, module3-lib and module4-lib still use a location hint to load the > schema. Fixed. > modules-21 is as follows: > It expects (non-existant) error XQST0081. I assume it should have been be > XPST0081 (unbound prefix). I agree. > However the imported module uses the schema with target namespace > "http://www.w3.org/TestModules/defs" and so I believe that XQST0036 is also > appropriate. > > This also applies to modules-23 and modules-24 I think that modules-23 doesn't use an undefined prefix, and should not therefore raise XPST0081. Otherwise agreed and fixed. > The tests modules-25, modules-26 and modules-27 all import module4-lib.xq Well, they did until a fix for Bug #9955 was committed which screwed them up. After a bit of CVS archaeology, I think the correct thing to do is to change them back to use module4-lib again. > In several places in this module a newly constructed attribute (with type > annotation xs:untypedAtomic) is used where a schema-attribute(sample:attrib) is > expected. Thus I believe any test importing this module should also expect > XPTY0004, which seems to undermine the test. Agreed. > The module could be fixed by validating the constructed attributes, although > this doesn't seem to be possible in XQuery (why can we only validate > elements?). The only way to fix this test is either to use the type > schema-attribute(sample:attrib)? and the value (), or to expand the schema such > that we can validate an element containing a sample:attrib attribute and then > extract the attribute. I've fixed these tests by making them accept zero-or-more schema attributes. > validate-constraints-1 - 4 are all marked isXPath2="true" when they are not > valid XPath 2 tests. Fixed. Again, please test the fixes, and mark the bug as closed if you agree with my solutions.
Thanks for your valiant efforts. You have fixed all the issues I listed. I'm afraid you haven't quite got off that easily though - One final tweak: (I assure you this will be the last time I reopen the bug!) modules-26 and modules-27 have an expected error code of XPST0081 (undefined prefix). This should be XQST0036 (Schema required for module not imported).
Once more with feeling... (In reply to comment #14) > modules-26 and modules-27 have an expected error code of XPST0081 (undefined > prefix). > > This should be XQST0036 (Schema required for module not imported). Agreed and fixed.