Skip to content

Commit

Permalink
Merge pull request #650 from michaelhkay/Issue649-xsl-fallback
Browse files Browse the repository at this point in the history 
649: fix an xsl:fallback problem
  • Loading branch information
@ndw
ndw committed Oct 16, 2023
2 parents 0e26cd8 + 1514dd8 commit e972dba
Showing 1 changed file with 48 additions and 6 deletions.
54 changes: 48 additions & 6 deletions specifications/xslt-40/src/xslt.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6819,9 +6819,17 @@ and <code>version="1.0"</code> otherwise.</p>
<p><termdef id="dt-effective-version" term="effective version">The <term>effective
version</term> of an element in a <termref def="dt-stylesheet-module"/> or <termref def="dt-package-manifest"/> is the decimal value of the <code>[xsl:]version</code> attribute
(see <specref ref="standard-attributes"/>) on that element or on the innermost
ancestor element that has such an attribute, excluding the <code>version</code>
attribute on an <elcode>xsl:output</elcode> element.</termdef></p>
<p>
ancestor element that has such an attribute, <phrase diff="chg" at="issue649">subject
to special rules for the <elcode>xsl:output</elcode> and <elcode>xsl:fallback</elcode>
elements.</phrase></termdef></p>
<p>These rules do not apply to the <elcode>xsl:output</elcode> element, whose
<code>version</code> attribute has an entirely different purpose: it is used to
define the version of the output method to be used for serialization.
The <termref def="dt-effective-version"/> of an <elcode>xsl:output</elcode> element
is the effective version of its parent element.</p>
<p>There are additional rules for an <elcode>xsl:fallback</elcode> element: see
<specref ref="forwards"/>.</p>
<p>
<termdef id="dt-backwards-compatible-behavior" term="backwards compatible behavior">An element is
processed with <term>backwards compatible behavior</term> if its
<termref def="dt-effective-version">effective version</termref> is less than
Expand Down Expand Up @@ -6867,9 +6875,7 @@ and <code>version="1.0"</code> otherwise.</p>
</note>
</item>
</ulist>
<p>These rules do not apply to the <elcode>xsl:output</elcode> element, whose
<code>version</code> attribute has an entirely different purpose: it is used to
define the version of the output method to be used for serialization.</p>




Expand Down Expand Up @@ -7152,6 +7158,34 @@ and <code>version="1.0"</code> otherwise.</p>
a separate module from the package manifest, and using the separate module as the
version of the stylesheet that is presented to a 2.0 processor.</p>
</note>
<p diff="add" at="issue649">For an XSLT 4.0 processor, the <termref def="dt-effective-version"/> of an
<elcode>xsl:fallback</elcode> element that has no explicit <code>version</code> attribute
is 4.0: more generally, it is the version of XSLT supported by the processor.
This rule is designed to ensure that the <elcode>xsl:fallback</elcode> element
itself is not processed with <termref def="dt-forwards-compatible-behavior"/>,
which would be pointless since the whole purpose of the instruction is to provide
code that can be evaluated with an earlier version of XSLT.</p>

<note diff="add" at="issue649">
<p>This rule was not present in earlier versions of this specification.
On a strict reading of the XSLT 3.0 specification, for example, an <elcode>xsl:fallback</elcode>
instruction with no <code>version</code> attribute is evaluated with forwards compatible
behavior. This means, for example, that if the stylesheet author writes
<code><![CDATA[<xsl:fallback select="42"/>]]></code> (which is incorrect, because
the instruction does not define a <code>select</code> attribute) then the <code>select</code>
attribute will simply be ignored.</p>

<p>Stylesheet authors can prevent this problem by adding an explicit
<code>version</code> attribute to <code>xsl:fallback</code> indicating the version
of XSLT that is needed to evaluate the fallback code.</p>

<p>This specification cannot retrospectively dictate what XSLT 3.0 (or earlier)
processors should do; however, developers of such processors are encouraged to adopt
this rule, so that in an XSLT 4.0 stylesheet, an <elcode>xsl:fallback</elcode> instruction
that cannot be properly evaluated by an XSLT 3.0 processor is rejected rather than
being silently ignored.</p>
</note>

</div2>
<div2 id="combining-modules">
<head>Combining Stylesheet Modules</head>
Expand Down Expand Up @@ -39268,6 +39302,7 @@ See <loc href="http://www.w3.org/TR/xhtml11/"/>
<item><p>The <elcode>xsl:matching-substring</elcode> and <elcode>xsl:non-matching-substring</elcode>
elements within <elcode>xsl:analyze-string</elcode> may take a <code>select</code> attribute
in place of a contained sequence constructor.</p></item>

<item><p>Simplified stylesheets no longer require an <code>xsl:version</code> attribute
(which means they might not need a declaration of the XSLT namespace). Unless otherwise
specified, a 4.0 simplified stylesheet defaults <code>expand-text</code> to <code>true</code>.</p></item>
Expand All @@ -39277,9 +39312,16 @@ See <loc href="http://www.w3.org/TR/xhtml11/"/>
transformation of JSON data structures (trees of maps and arrays) to work in the same way as with
XML-derived data structures.</p></item>


<item><p>The streamability rules for accumulators have been relaxed, so that the <code>phase="end"</code>
processing has access to the full subtree of the matched node.</p></item>

<item><p>The <termref def="dt-effective-version"/> of an <elcode>xsl:fallback</elcode>
instruction with no <code>version</code> attribute is the version of XSLT supported
by the processor, so that the <elcode>xsl:fallback</elcode> is not itself processed
using <termref def="dt-forwards-compatible-behavior"/>.</p></item>


</olist>
</div3>
</div2>
Expand Down

0 comments on commit e972dba

Please sign in to comment.