Usability is measured primarily by the quality of the error messages. This is not yet as good as the Java validator. Here is the validation report produced for the invalid booklist document supplied earlier:
<vr:validation-report xmlns:vr="http://saxon.sf.net/ns/validation">
<vr:error path="/Q{}books[1]/Q{}book[1]/Q{}date[1]">Element date is not allowed
here</vr:error>
<vr:error path="/Q{}books[1]/Q{}book[2]/Q{}author[1]">Element author is not
allowed here</vr:error>
<vr:error path="/Q{}books[1]/Q{}book[2]"> must satisfy assertion
if (publisher eq 'McGraw Hill')
then starts-with(@isbn, '007')
else if (publisher eq 'Academic Press')
then starts-with(@isbn, '012') else true()</vr:error>
</vr:validation-report>In comparison with the report produced by the Java validator, we see:
There are no line and column numbers associated with the errors, only a path. This omission is because XSLT provides no standard way of obtaining the line or column number of a node. Some versions of Saxon provide extension functions to get this information, but we want to avoid using extensions; and in any case, a key target environment is Saxon-JS, where we rely on the Javascript DOM as our data model, and the Javascript DOM does not provide line and column information.
There is no information about which constraint in the XSD specification is violated (this information is of little value to most users, but it is required by the conformance rules).
There are only three errors reported, rather than five. This is because the XSLT validator is quicker to stop validating sibling elements once one of them has been found to be in error.
So there is some work still to be done to get the usability up to the level of the existing validator.