This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section 2.8 (Stylesheets and XML Schemas) of the XSLT 2.0 spec, the distinction of a "basic XSLT processor" and "Schema Aware XSLT processor" is not clear. The distinction is described as (it seems to me..) - A stylesheet that works with a basic XSLT processor will work unchanged with a schema-aware XSLT processor, unless the type information created as a result of schema processing introduces type errors (for example, an attribute of type xs:date cannot be used as an argument of the substringFO function), or unless the type information changes the outcome of operations such as comparison and sorting. This appears quite confusing .. I think it should be a bit more clear ... Regards, Mukul
I'm inclined to agree with you. The current statement is a bit too much like one of those marketing brochures that starts with the comfort statement "It's exactly the same" and then lists some differences, trying to make it look as if the differences are small. It would be better to be upfront and say that there are some differences in behavior in the two cases, giving some examples. I shall treat this as editorial.
I have made changes to this paragraph which I hope you will find satisfactory. It now reads: The conformance rules for XSLT 2.0, defined in [], distinguish between a basic XSLT processor and a schema-aware XSLT processor. As the names suggest, a basic XSLT processor does not support the features of XSLT that require access to schema information, either statically or dynamically. A stylesheet that works with a basic XSLT processor will produce the same results with a schema-aware XSLT processor provided that the source documents are untyped (that is, they are not validated against a schema). However, if source documents are validated against a schema then the results may be different from the case where they are not validated. Some constructs that work on untyped data may fail with typed data (for example, an attribute of type xs:date cannot be used as an argument of the substring function) and other constructs may produce different results depending on the data type (for example, given the element <product price="10.00" discount="2.00"/>, the expression @price gt @discount will return true if the attributes have type xs:decimal, but will return false if they are untyped). Please feel free to reopen the bug if you think this can be improved further.