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 way in which the tests in test-set app-Walmsley use relative URIs is inconsistent with other parts of the test suite and creates difficulties for the test driver. A typical example is test d1e11215, which includes the function call doc("catalog.xml") This is intended as a reference to the resource described in the environment as <source role="." file="Walmsley/catalog.xml" uri="catalog.xml"/> The query is in an XML file /some/path/app/Walmsley.xml and the required file can be found in /some/path/app/Walmsley/catalog.xml The problem is that the doc() function is supposed to resolve the relative URI against the base URI of the query, and the base URI of the query is file:///some/path/app/Walmsley.xml. The absolute URI is therefore file:///some/path/app/catalog.xml and it's difficult from this to identify the <source> element in the environment. It works if (in JAXP, for example) you can write a URIResolver that is given the base URI and the relative URI separately, but the language specs don't encourage that: whereas it's fine for the absolute URI to be redirected by some external lookup mechanism ("the static context") there's no suggestion in our specs of the JAXP mechanism where the relative and base URI are separately available to the lookup mechanism. It's tempting to suggest fixing this by adding a <static-base-uri> element to the environment, but the test catalog specification says that this must be an absolute URI. I therefore suggest that we should change these tests to use relative URIs that resolve properly, without redirection, to the documents that the tests are intended to use.
I have modified the environment to supply an absolute static-base-uri, and use this for the supplied resources, as per Mike's first suggestion (this was decided to be less disruptive than modifying the relative URIs in lots of tests individually). This fix broke the test d1e78807b, which uses fn:transform() and saves the output to the supplied base-output-uri. So I have modified this test (and its environment) to use relative URIs that resolve properly (without redirection). Apologies for getting this wrong in the first place. Note that the tests were supplied by Priscilla Walmsley, but I added the test set to the test suite, supposedly after sorting out any issues...
Due to this change, the discussed tests are now failing with our test engine. I am sorry I cannot give an easy explanation so far; it will take me some more time to find out what’s the new problem. I managed to locally fix the test case issues by replacing all occurrences of doc("catalog.xml") with doc("http://www.w3.org/2010/09/qt-fots-catalog/Walmsley/catalog.xml"). Do you think this would be an option? Are there some other implementors out there that have similar problems with the changes?
I still have no idea how to properly resolve the static base uri in this context (and I am pretty sure I would only need it to do justice to these few test cases). I didn’t find a similar pattern in the other test cases that use fn:doc (in most of them, the URI seems to be bound to a variable), but I noticed that things are (I believe) handled more easily in other test cases. See "UseCaseR31-030" for example: It directly addresses "UseCaseR31/Wikipedia-Origami.xml" in the doc function, and there is not source element addressing it. Maybe things can be resolved as follows? a) address the document via "Walmsley/catalog.xml" b) drop the old <source> element <source role="." file="Walmsley/catalog.xml" uri="catalog.xml"/> c) update the test cases (d1e41635, d1e41648?) that rely on the context item
I think the tests are correct as written and the pattern is consistent with other tests such as those in unparsed-text-available using the environment unparsed-text-available-with-base-uri. The relative URI supplied to the doc() function is resolved against the static base URI defined in the test environment to give an absolute URI equal to that under which the document is registered in the environment; I'm not sure which part of this mechanism you think is wrong.
Thanks for your feedback, Michael. In that case, I will spend some more time on our test suite. I would like to hear your opinion about test case "UseCaseJSON-008", which resembles the old app-Walmsley pattern: https://github.com/LeoWoerteler/QT3TS/blob/master/app/UseCaseJSON.xml#L225-L244 https://github.com/LeoWoerteler/QT3TS/blob/master/app/UseCaseJSON.xml#L57-L60 Do you think that a static base URI needs to be added for this test case as well?
Yes I agree the test case UseCaseJSON-008 requires the same fix. Fix committed to cvs.