This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
fn-document-uri-12 results are wrong. The specification of the document-uri() accessor in the data model says that the result will always be either an absolute URI or the empty sequence. In this situation, either of these results should be accepted, since it depends on the test driver whether an absolute URI is available for the document. But a relative URI, as in the expected results, is always wrong.
Similar considerations apply to document-uri-15 to 21. Note that the absolute URIs of source documents in the test suite depend entirely on the filestore layout of the machine where the tests are executed. A better technique is needed here for producing reproducible test results: for example, testing whether the document-uri ends with a particular string.
I agree with Michael's comment, and also point out that the document-uri accessor may return the empty sequence for a number of reasons. Section 5.4, document-uri Accessor, of Data Model says: "If there is no URI available, or if it cannot be made absolute when the Document Node is constructed, or if it is used on a node other than a Document Node, the empty sequence is returned."
I think I got around the problem (somewhat). I refocused the tests by concentrating on the presence of the "works-mod" string within the returned value of "fn:document-uri". At this point I am not accounting for the return of the empty string, but hoping that such scenario will not happen. Please feel free to either close or reopen the bug, though I will admit this may be a somewhat cumbersome solution. Thanks, Carmelo
This sounds like an improvement. Another suggestion would be to apply document-uri() to the result of the doc() function, on the basis that there's a guarantee that let $X := doc('xyz') let $Y := document-uri($X) let $Z := doc($Y) return ($X is $Z) returns true, provided doc('xyz') actually succeeds.