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 following tests call doc($input-context) but the catalog sets $input-context up as a document node of a specified file (works-mod in the case of -5) This means that the argumemt to doc() is the string value of the entire external document, which typically isn't a legal URI,and certainly doesn't resolve to an xml document. Presumably the catalog needs to specify these external variables as strings rather than files although the test harness may need to be given licence to adjust the relative reference to fit local conditions. fn-doc-5 fn-doc-6 fn-doc-7 fn-doc-8 fn-doc-9 fn-doc-10 fn-doc-11 fn-doc-12 fn-doc-13 fn-doc-14 fn-doc-15 fn-doc-16 fn-doc-18 fn-doc-19 fn-doc-20 fn-doc-21 fn-doc-22
I agree. I believe that the query for fn-doc-5 should be: $input-context is $input-context The input-file element should specify: <input-file role="principal-data" variable="input-context" context="doc">works-mod</input-file>
> $input-context is $input-context yes I wondered about that possibility before posting. That makes the test internally consistent, but the test name and the embedded comment imply that it is explicitly testing the doc function which it isn't (or may not be) if you just test the input variable. You could pass in a string using the mechanism used for external variables but that seems pretty heavyweight (I'm struggling to modify my test harness for that at the moment) but simpler would be to have a new catalog element that could supply a string value rather than a file name to initialise the variable. David
Maybe it would be easiest to have a <query-param> element with a type (doc, query, string)?
*** Bug 2991 has been marked as a duplicate of this bug. ***
Just for the record, this problem is still present in XQTS 0.9.0
Michael/Per/martin/David: Thanks for raising this issue. I corrected most of the tests. For the most part the fixed was either: 1) change query to use just use $input-context1 insted of "fn:doc($input-context)" as suggested. Changed the test case entry to specify context="doc" for the "input-file" element. 2)For some tests, istead of using $input-context, I specified the name of the input file directly into the query as this examples shows: "fn:doc(fn:concat("works-mod.xml",()))//day". We are testing fn:doc after all. This seems to work. Please close the bug if this is satisfactory. Thanks Carmelo
fn-doc-8 now has: fn:doc(fn:lower-case(fn:upper-case("works-mod.xml")))//day This will only work as intended if the relative URI "works-mod.xml" resolved against the base URI in the static context finds the file in the test sources directory. This isn't going to work without special casing an entity resolver somewhere, and there is no information in the catalogue that any such resolution is required. The test should be modified to either pass in the file name as an external variable which may be set by the test harness using the current indirection provided by the catalogue <source ID="works-mod" system, or it needs to set it in a variable in the commented "magic" area of the query and give test implementers licence to change it to a URI that will work in their system. You might want to make the default be the relative URI from the Query to the file as it is distributed, so "../../../../../TestSources/works-mod.xml" not "works-mod.xml" then a system such as xq2xsl (and saxon) that sets the default base URI in the static context to be the URI of the query file have a chance of passing this. David
(In reply to comment #7) > or it needs to set it in a variable in the commented "magic" area of the query > and give test implementers licence to change it to a URI that will work in > their system. You might want to make the default be the relative URI from the > Query to the file as it is distributed, so > "../../../../../TestSources/works-mod.xml" I would hope for external variables as I feel modifying the query using regexps or whatever is a huge pain. We have a system for external variables and all the flexibility of an XML document, so please use it.
> I would hope for external variables as I feel modifying the query using regexps > or whatever is a huge pain. No disagreement here. If the WG were not trying to reach the finish line I'd recommend that the whole mechanism of modifying the Query source be dropped, especially changing schema imports to namespace declarations almost always just results in processors being allowed to get an unintended result. > and all the flexibility of an XML document, so please use it. Ah yes, well, I first convert the xquery source to xml then do the modifications, so that's less of an issue for me:-)
Comments on the current state of these tests. fn-doc-5 now reads $input-context is $input-context No problem, except that the test description says "Evaluation of fn:doc as per example 1 from the functions and Ops. for this function" which might mean we don't actually have the test coverage that we think we have So fn-doc-5 is not testing fn:doc and are not doing what the test description says it is doing. The same goes for fn-doc-6, 7, 18, 19, 20, 21, 22. These tests as now written are useless. fn-doc-8 reads fn:doc(fn:lower-case(fn:upper-case("works-mod.xml")))//day This is the subject of previous comments. I would advocate putting a copy of works-mod.xml in the directory containing fn-doc-8.xq - that seems the simplest solution at this stage. fn-doc-9-16 - same issues as 8, all will be solved by copying works.xml This still leaves us with the unsatisfactory situation that we are only actually testing one call on fn:doc, namely fn:doc('works.xml') with various different ways of constructing the argument string and using the result. Given the complexity of this function, this seems a bit unfortunate. On the other hand, since most of the complexity is environmental, it's hard to know what to suggest. But a few tests showing use of absolute and relative URIs and the interaction with base URI would certainly be useful.
Michael et all: I will take a second look in the morning. The problem with "fn:doc" is that is does not lend itself easily for testing. Carmelo
All: Let me throw this your way. I think that seting: declare base-uri "../../../../../TestSources and then a query like fn:doc(fn:lower-case(fn:upper-case("works-mod.xml")))//day should work for all implementations?, Correct or am I missing something? Carmelo
(In reply to comment #12) > am I missing something? Well, there is a problem in that the XQuery specification requires the Base URI to be absolute.
There is that little detail .....
Not quite for X-Hive/DB, but that's because of our test harness. I actually only load the documents that are needed for the particular test case, run the (single) test, and clean the database afterwards. This is mainly because of our data modifying tests that use the same infrastructure. So in X-Hive/DB there's always just a single '/works.xml' document in the DB for that test. This is why I'd prefer no hardcoded URI in the query but rather a parameter to the query that gives the test harness the power to provide a implementation defined URI.
I don't think that the query test files should have any paths (or even local filenames). The catalogue system always uses indirection to avoid refering to any file names and just has one local place in the catalogue where a file paths/URIs can be customised to local needs. If you need to refer to a works-mod.xml you need somehow to refer to the element <source ID="works-mod" and then the implementer can use the catalogue information to customise the actual file (or database node or whatever) that needs to be accessed. Why can't you just have a query that looks like doc($foo) and have a catalogue element that specifies that the external element foo is to be set to a string representing a uri to the file with ID "works-mod" actually xq2xsl test harness does just read the files off the filesystem from locations produced by unzipping the test suite, so a path of ../../.... would work for me, but the system should not assume that.
Dave: Your suggestion is simple enough and workable for everyone. I will modify the guidelines as to give implementers more flexibility on handling the fn:doc function tests and replace $input-context1 (for instance) with whatever string represents the uri for the element whose ID is "works-mod" or "works" (whichever is the case). Hopefully this will put this issue to rest. Thanks, Carmelo
Michael/Dave et all: Regarding fn:doc tests. 1) Changed guidelines to allow test suite runners to substitute the external reference ($input-context) by the URI of the file ("works-mod") 2) Query may make reference to more than one file. Use the file mapping given on test-case element. Hopefully this will work for everyone. Submitted new tests.
thanks