This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Description ----- If the library is extended with new tests, it is likely that these new tests extend the AbstractXSLTTestImplementation class. The problem is that this class will search for the underlying XSLT stylesheet in a specific location within the JAR based on the namespace of the mobileOK tests: org/w3c/mwi/mobileok/basic/xslt/ This makes it hard to use AbstractXSLTTestImplementation for new tests, because new tests are unlikely to match that namespace. Solution ----- I guess the best way to change that is for AbstractXSLTTestImplementation to use relative paths. That needs to be done carefully, as the URI resolver that is passed along to the SAXTransformer also needs to use the same algorithm to resolve xsl:import statements within stylesheets. getClass().getResourceAsStream() needs to be used if we are to use relative paths (and not getClassLoader().getResourceAsStream()). It probably means that we need to implement DOMUtils.getResourceStream within AbstractXSLTTestImplementation.
Changes on ClasspathURIResolver ----- ClasspathURIResolver now awaits an object when it is instantiated. The object's namespace is used to resolve the appropriate path to the XSLT stylesheets. The namespace used by default when no object is given is that of the ClasspathURIResolver: org/src/mwi/mobileok/basic More precisely, the relative URI to the stylesheet is understood as: 1. referring to a resource, whose base namespace is the one of the above object completed with the value of the XSLT_PATH static variable ("xslt/") 2. referring to a file, whose base path is constructed using the: BUILD_PATH + [namespace of the above object] + XSLT_PATH formula starting from the root of the project 3. referring to a resource, whose base namespace is the one of the above object 4. referring to a file, whose base path is the root of the project The whole list is not fully needed, but brings a bit more of flexibility and should not create any problem. Changes in AbstractXSLTTestImplementation ----- The AbstractXSLTTestImplementation still uses the name of the class that extends the class to build the name of the XSLT stylesheet to search for, but it now searches for non a precompiled stylesheet when the precompiled stylesheet cannot be found. For performance reasons, the precompiled option is still strongly encouraged, but it makes it possible to run the Checker in debugging environments without precompiled versions of the stylesheets. Example ----- Suppose the class that extends AbstractXSLTTestImplementation is: org.example.mytest defined in the org/example folder. "mytest.sxx" will be searched: * as a resource in org/example/xslt/mytest.sxx * as a file in build/org/example/xslt/mytest.sxx * as a resource in org/example/mytest.sxx * as a file in mytest.sxx If still not found, "mytest.xsl" will be searched for in the same locations.