W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2005

[Bug 1230] Rules for forwards-compatibility mode

From: <bugzilla@wiggum.w3.org>
Date: Thu, 28 Jul 2005 22:57:05 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DyHJJ-0004Oe-HU@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1230


mike@saxonica.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From mike@saxonica.com  2005-07-28 22:57 -------
Following discussion, the working group decided that the new use-when attribute
meets many of the requirements that originally relied on forwards compatibility
mode, and that it was therefore possible to reduce the differences that apply in
this mode. In particular, the existing design causes static errors to be demoted
to dynamic errors so that version-specific code can be made conditional using
xsl:choose; this is no longer necessary given that we now have a compile-time
conditional. The forwards compatibility section is therefore rewritten as follows:

        <p>The intent of forwards-compatible behavior is to make it possible to
write a stylesheet that takes advantage of features introduced in some version
of XSLT subsequent to XSLT 2.0, while retaining the ability to execute the
stylesheet with an XSLT 2.0 processor using appropriate fallback behavior.</p>

<p>It is always possible to write conditional code to run under different XSLT
versions by using the <code>use-when</code> feature described in [XXX]. The
rules for forwards-compatible behavior supplement this mechanism in two
ways:</p>

<ulist>
<li><p>certain constructs in the stylesheet that mean nothing to an XSLT 2.0
processor are ignored, rather than being treated as errors</p></li>

<li><p>explicit fallback behavior can be defined for instructions defined in a
future XSLT release, using the <elcode>xsl:fallback</elcode> instruction.</p></li>
</ulist>

<p>The detailed rules follow.</p>


<p><termdef id="dt-forwards-compatible-behavior" term="forwards-compatible
behavior">An element enables <term>forwards-compatible behavior</term> for
itself, its attributes, its descendants and their attributes if it has an
<code>[xsl:]version</code> attribute (see <specref ref="standard-attributes"/>) 
whose value is greater than <code>2.0</code>.</termdef></p>

<p>An element that has an <code>[xsl:]version</code> attribute 
whose value is less than or equal to <code>2.0</code> 
disables forwards-compatible behavior for itself, its attributes, its
descendants and their attributes.
The compatibility behavior established by an element overrides
any compatibility behavior established by an ancestor element.</p>

<p>These rules do not apply to the <code>version</code> attribute
of the <elcode>xsl:output</elcode> element, which has an entirely different
purpose: it is used to define the version of the output method to be used for
serialization.</p>

<p>Within a section of a <termref def="dt-stylesheet">stylesheet</termref> where
forwards-compatible behavior is enabled:</p>

<ulist>
<item>
<p>if an element in the XSLT namespace appears  as a child of the
<elcode>xsl:stylesheet</elcode> element, and XSLT 2.0 does not allow such
elements to occur as children of the <elcode>xsl:stylesheet</elcode> element,
 then the element and its content <rfc2119>must</rfc2119> be ignored.</p>
</item>

<item>
<p>if an element has an attribute that XSLT 2.0 does not allow the element to
have, then the attribute <rfc2119>must</rfc2119> be ignored.</p>

<p>if an element in the XSLT namespace appears as part of a 
<termref def="dt-sequence-constructor">sequence constructor</termref>, and XSLT
2.0 does not allow such elements to appear as part of a sequence constructor,
then:</p>

  <olist><li><p>If the element has one or more <elcode>xsl:fallback</elcode>
children, then no error
  is reported either statically or dynamically, and the result of evaluating the
instruction is the concatenation of
  the sequences formed by evaluating the sequence constructors within its 
  <elcode>xsl:fallback</elcode> children, in document order. Siblings of the
<elcode>xsl:fallback</elcode>
  elements are ignored, even if they are valid XSLT 2.0 instructions.</p></li>

  <li><p>If the element has no <elcode>xsl:fallback</elcode> children, then a
static error is reported in the
  same way as if forwards-compatible behavior were not enabled.</p></li>
  </olist>
</item>
</ulist>

Since the bug was raised internally within the WG, it will now be closed.

Michael Kay
for the XSL WG
Received on Thursday, 28 July 2005 22:57:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:25 UTC