This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Context ----- The URI of the retrieved resources appears in three different places in each resource section in the moki representation: (1) under URI (except for the primary document, see bug 6819) (2) under retrieval/retrievedURI (3) under retrieval/HTTPRequest[1]/URI (there could be more than one HTTP request, the first de facto contains the initial URI of the resource) XSLT stylesheets should be as generic as possible and use 1. whenever possible, followed by 2. and then 3. (possibly not limited to the first HTTPRequest in the list if the goal is to get the "final" URI of the Resource, and not the initial one). They should be generic so as not to bind the tests to any specific scheme (there may be no retrieval information in the moki representation, or the scheme may not be HTTP). This would allow tests to be reused in extensions. Bug --- - CharacterEncodingSupportTest.xsl uses (3) for no apparent reason. - functions.xsl uses (3) in moki:get-retrieved-resource - several XSLT stylesheets use (2). Pending resolution of bug 6819, this should be updated to (1).
Some corrections/precisions: - CharacterEncodingSupportTest.xsl uses (3) for no apparent reason. That is not true! CharacterEncodingSupportTest needs to use (3) to return the exact URI that returned the incorrect HTTP Content-Type header. There is nothing we can do here, the test is bound to HTTP anyway. - functions.xsl uses (3) in moki:get-retrieved-resource ... for a good reason, as the base URI needs to be resolved against the final URI of the primary document, not against the initial URI of the primary document. We'll have to find a way to represent this final URI in a scheme-independent way, probably talking about "request" and "response" instead of "HTTPRequest" and "HTTPResponse".
All XSLT stylesheets updated to use primaryDoc/URI (1), except for the two exceptions highlighted in previous comments that need retrieval/HTTPRequest[1]/URI (3). The retrieval/retrievedURI (2) element is still present in the moki but should now be viewed as obsolete. It is not (or should not be) referenced anywhere in the code anymore. A more generic representation of the retrieval of a resource is still needed, see bug 6822 for more details on this.