A few of the XSLT tests still depend on Java functions to perform complex tasks that cannot be easily done in XSLT (e.g. advanced string manipulations).

These Java functions are called from within the XSLT stylesheet using a non standard feature specific to Saxon. This makes it hard to switch to another XSLT engine if needed. Also, this possibility has been removed from the latest basic edition of Saxon (Saxon-HE), thus the mobileOK Checker can but stick to Saxon-B version 9.1.

The moki representation, which already contains validation information (markup, CSS, encoding) should rather be completed with the information needed to perform the tests using pure XSLT.


Java functions are used:


1. to validate URIs
-----
Needed in moki:get-retrieved-resource in functions.xsl.
Solution here is probably to add a "m:validUri" attribute to all elements with URIs that need to be checked in docContent (base, img, and object). Another possibility would be to add the absolute URI of the element, so that the link with the retrieved Resource can be more easily determined. The flag probably takes less room.


2. to check cache-related settings
-----
Needed in CachingTest.xsl to send another request and check ETag and Last-Modified.
Solution is again to do the validation upfront while assembling the moki.


3. to check a few HTTP header fields
-----
Needed in CachingTest.xsl in particular.
Solution is probably to add a "m:valid" attribute to elements needed in the retrieval section in the moki.


4. to tell which CSS media types are targeted by a given piece of CSS
-----
Needed in StyleSheetsUseTest.xsl.
Solution is probably to add the CSS media types that embedded and external CSS really target (i.e. the ones advertized coupled with the ones really used) somewhere in the stylesheet element in the moki.


5. to check the inputmode attribute
-----
Needed in DefaultInputModeTest.xsl
Solution is again to add a "m:valid" attribute to the appropriate "input" element in docContent in the moki.


Another possibility would be of course to switch these tests to pure Java tests. A solution between those two extremes would be to run the tests in two steps:
 - first step run in Java to complete the moki with the information needed
 - second step uses only standard XSLT to build the report.
(only MEASURES and STYLE_SHEETS_SUPPORT are defined as "non-XSLT" tests for the time being, and could likely be converted to semi-XSLT tests if that's possible)