We have already mentioned that XSLT 3.0 can only generate a typed result tree (specifically, a node with non-trivial type annotations) by invoking a schema validator to produce the type annotations, and this precludes the possibility of writing that schema validator in XSLT 3.0. So the first obvious restriction we have to live with is that our validator will only do that part of the job concerned with detecting invalidity, not the other part concerned with augmenting the supplied instance with type information.
Unfortunately, even the task of distinguishing valid from invalid documents requires some use of type information associated
with nodes. The most obvious example is that assertions (XPath expressions in xsd:assert
declarations) are defined
to operate on "semi-typed" data - that is data that has been validated using all the constraints in the schema other than assertions,
and typed accordingly. For example, if @price
and @discount
are attributes of type xs:decimal
,
then the assertion test="@discount lt @price"
is defined to do a decimal comparison, not a string comparison.
We don't currently have a solution to this problem. We found, however, that very few schemas are affected. With such schemas,
it is currently necessary to rewrite the assertion to do explicit typing: in this case
test="xs:decimal(@discount) lt xs:decimal(@price)"
Another case where typed data can be important is in key
and keyref
constraints. For example,
if a uniqueness constraint applies to an attribute @birthDate
of type xs:date
, then values of that
attribute are compared as dates, not as strings. Again, we found that this is rarely a problem in practice, but in this case
we do have a solution that covers most cases: by doing static analysis of the XPath expressions used in the selector
and field
elements of the constraint, we can usually determine the data type of the values these expressions are
selecting, and we can put this inferred type into the SCM and use it to cast the values before comparison. The only case where
this approach proves inadequate are pathological cases where the type cannot be statically inferred, for example when the XPath
expressions use union types or wildcards.