[Bug 1230] Rules for forwards-compatibility mode

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





------- Additional Comments From mike@saxonica.com  2005-05-29 22:53 -------
Some further observations:

I've been running my 2.0 tests through my 1.0 processor to see what happens.

One observation is that <xsl:value-of> with no select attribute fails. There's
nothing in the 1.0 rules for forwards compatibility that says a 1.0 processor
should anticipate that an attribute that's mandatory in 1.0 might become
optional in 2.0. Logically one should add the rule that in forwards compatible
mode, the absence of a mandatory attribute is an error only if the instruction
is actually evaluated.

Another observation: I found myself wanting to mark a stylesheet as being
suitable for use only with XSLT 2.0, so that a 1.0 processor would reject it.
The most effective way of doing this, perversely, is to specify version="1.0",
so that a 1.0 processor will report any 2.0 constructs as errors, while a 2.0
processor runs the stylesheet happily. It's not easy to see a way around this.
One way might be to allow the syntax

   version="2.0 only"

   (or version="2.0 and above")

which a 1.0 processor will reject as an invalid version attribute.

In the 2.0 appendix on backwards compatibility, we fail to mention that a
stylesheet that uses XSLT 2.0 constructs and specifies version="2.0" may produce
different results when run on a 1.0 processor (in FC mode)and when run on a 2.0
processor. Some cases where this happens include:

(a) <xsl:attribute name="x" select="12"/>

    A 2.0 processor outputs a="12", a 1.0 processor in fcm outputs a="".

(b) <xsl:character-map>

    A 1.0 processor in fcm ignores this element

(c) <xsl:apply-templates mode="#current"/>

    A 1.0 processor in fcm ignores the mode attribute




Michael Kay

Received on Sunday, 29 May 2005 22:53:17 UTC