This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec currently says: [ERR XTSE1660] A basic XSLT processor must signal a static error if the stylesheet includes an [xsl:]type attribute, or an [xsl:]validation or default-validation attribute with a value other than strip. It would be useful if it was "lax" as well as "strip". This would allow transforms to work on both basic and schema-aware processors with minimal impact on the stylesheet: <xsl:import-schema ... use-when="system-property('xsl:is-schema-aware')='yes'"/> <xsl:document validation="lax"> (or collection(.... ?validation=lax) ) <xsl:result-document validation="lax"> Currently the basic processor complains about validation="lax" even though it could safely ignore it. To work around this, you have wrap your input/output in both is-schema-aware = yes and no and its just extra hassle.
Noted that it would be nice to make it easier to write stylesheets that work across both environments. Noted in discussion that this might cause an incompatibility between a basic and a schema-aware processor in a situation like <thing xsl:validation="lax" xsi:type="xs:integer">93.7</thing> Kept open for the moment.
[Speaking only for myself] I'm finding this a difficult design issue. Pro: 1) It would indeed reduce the need for xsl:use-when, when writing stylesheets that should exploit schema-awareness when present but carry on regardless when invoked with a non-schema-aware processor. Other things being equal, that's a good thing. And there is a sense in which the keyword "lax" is intended, precisely, to express the desire that schema information should be used if present, but that its absence should not cause an error (or an invalidity). This case is slightly different from the case of lax wildcards (schema information vs. schema awareness), but there does seem to be an analogy. 2) If we imagine a schema-aware processor that loaded no schema documents and worked from an empty schema, it feels reasonable to expect that in validating documents it would behave like a schema-oblivious processor. Con: 3) No schema-aware processor ever works with an empty schema: the built-ins are always present (that's what it means to be built-ins). So a schema-aware processor is never oblivious to invalid instances of integer, or QName, or any of the other built-ins. 4) So (as noted in comment #1) following the suggestion made here would lead to incompatible behavior between schema-aware and -oblivious processors. Against argument 4: 5) If the suggestion made in this bug report is NOT adopted, the implicit advice is to use use-when to get the desired result. If the stylesheet author follows this advice, the stylesheet will have: <thing xsl:use-when="system-property('xsl:is-schema-aware')='yes' xsl:validation="lax" xsi:type="xs:integer" >93.7</thing> <thing xsl:use-when="system-property('xsl:is-schema-aware')='no' >93.7</thing> Here we still have the phenomenon that the schema-aware processor throws an error, and the other processor doesn't. And we have the further discrepancy that one of them emits an xsi:type attribute and the other doesn't. Is this an improvement? Possible compromise: Require basic processors to throw the error in question when and only when xsi:type (etc.) name one of the XSD built-ins? Or anything at all in the XSD namespace? I'm not sure about this; it might feel simpler just to do as suggested in comment 0.
The WG discussed this on 5 March 2009 and agreed that the change was, on balance, a desirable one. However we felt that it was a design change rather than an error fix, and it would not be appropriate to implement it by means of a 2.0 erratum. It will therefore go into the specification of XSLT 2.1. I am changing the component to XSLT 2.1, and marking the problem as fixed. If this resolution is acceptable, I would be grateful if you (Andrew Welch) could mark the bug as closed. [XSLT 2.1 baseline spec updated.]
Done.