This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This uri attributes of the sources in this file are not absolute. The documentation states "The URI should always be an absolute URI."
I cannot find this requirement anywhere. Sources in all test-set files are relative, as far as I can see. But considering this was reported over a year ago, it may have been taken over by events. I will resolve this without action, please reopen if the issue still persists.
From catalog-schema.xsd: <xs:attributeGroup name="uriAttr"> <xs:annotation> <xs:documentation> <div> ... <p> The URI should always be an absolute URI. </p> ... </div> </xs:documentation> </xs:annotation> <xs:attribute name="uri" type="xs:anyURI"/> </xs:attributeGroup> but _merge-test-set.xml contains, for example: <source file="log-file-1.xml" uri="log-file-1.xml"/>
Ah, I see now. I was looking in the WD's. I would consider this documentation in error, I don't see how this can/should work with absolute URIs (afaik, we always use relative uris). Use relative URIs makes it easier to run the tests from any location. I will update the documentation to reflect this. If you think this should be an absolute URI, let me know.
I think the documentation is correct. It follows the policy from the CQuery test suite, and I think this is followed in the XSLT test suite with the one exception given in this report (but I'd have to check),
Sorry, it looks like my comment was about the file attribute, not the uri, as you said in comment#0, my bad. Looking more closely at it, I decided to do a quick search. In QT3 I find that both practices are used, for instance some examples with uri attribute relative are: fn-doc-24 through to fn-doc-37 UseCaseJSON origami environment fn-doc-available-4 and 4 Some others use an absolute URI. However, doing the same search on XT3, it's even worse. Total of 107 with a uri attribute and *all* of them have a relative uri (despite what is said in the XSD), including very old tests, see the document and collection tests for instance. This may not be relevant for the tests if the test itself does not use the URI for resource location, merely the file reference, but I agree it appears an erroneous, if not at least confusing, practice. I am not sure if we should attempt to fix these 107 items. I think they kind of behave equal to the 662 items *without* a URI, in that only the file location is known. I could, to remove the confusion, remove all these uri attributes, as they seem to have no relevance to the tests.
I am moving forward and resolve this bug as won't fix, I don't think we should make it a requirement for those 107 tests to have an absolute URI, allowing it to be relative to the base of the document it contains works for me. We can update the documentation to signify this. If you disagree, please let me know how you would wish to proceed.