- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 29 May 2005 22:53:12 +0000
- To: public-qt-comments@w3.org
- Cc:
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