This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3.9 (Forwards compatible processing) says: Within a section of a stylesheet where forwards-compatible behavior is enabled: if an element in the XSLT namespace appears as part of a sequence constructor, and XSLT 2.0 does not allow such elements to appear as part of a sequence constructor, then: 1. If the element has one or more xsl:fallback children... 2. If the element has no xsl:fallback children, then a static error is reported in the same way as if forwards-compatible behavior were not enabled. This would imply that error XTSE0010 is raised. However we have a specific error XTDE1450 that covers this case: [ERR XTDE1450] When a processor performs fallback for an instruction element, if the instruction element has one or more xsl:fallback children, then the content of each of the xsl:fallback children must be evaluated; it is a non-recoverable dynamic error if it has no xsl:fallback children. Note however that this is a dynamic error rather than a static error. This appears to be a relic of the pre-"use-when" situation. We've been moving towards raising static errors for such conditions. I propose (a) that we modify the rule cited for forwards compatibility to replace the phrase "as if forwards-compatible behavior were not enabled" with a reference to error 1450, and (b) that error 1450 becomes a static error, changing its code to XTSE1450.
Following discussion in an XSL WG telcon, it emerged that we need to distinsguish two cases: (a) use of undefined XSLT instructions in forwards compatible mode, and (b) use of unrecognized extension instructions. In case (a) we want this to be a static error unless xsl:fallback is defined. In case (b) we want this to be a dynamic error that happens only if the extension instruction is actually evaluated (and there is no fallback). If this is what we want, then section 3.9 is OK, but we need to change section 18.2.3 (Fallback): * move the error condition to the end * make it clear that it applies only to the "extension instruction" case * cross-refer to section 3.9 for handling of the "new XSLT instruction" case
The WG agreed to the changes proposed for section 18.2.3, and these changes have now been applied.