xsl:fallback

[michaelhkay]

I made the mistake of writing a test that said:

    <xsl:array version="4.0">
      <xsl:fallback select="array{1 to 10}"/>
      <xsl:sequence select="1 to 10"/>
    </xsl:array>

Now, the xsl:fallback instruction doesn't allow an @select attribute; and there's not much point in adding one, because xsl:fallback is only there for a processor implementing XSLT 1.0, 2.0, or 3.0, and such processors will ignore anything the XSLT 4.0 specification says.

However, we could supply some clarification of what such a processor is expected to do when it finds an xsl:fallback element with an unexpected @select attribute. At present, it seems that because we don't say anything else, the xsl:fallback element is itself evaluated in forwards compatibility mode, which means that the select attribute is ignored. Since the whole purpose of xsl:fallback is to provide code that an earlier XSLT processor can handle, I think it would make much more sense to say: "the effective version for an xsl:fallback element and its descendants, unless overridden with an explicit [xsl:]version attribute, is the version of the processor in use", so a 3.0 processor executing an xsl:fallback instruction in a 4.0 stylesheet reports a static error if it finds a construct like the above.

Although the 4.0 spec cannot dictate what a 3.0 processor does, we could add a non-normative note encouraging this interpretation.