Are you saying MSXML4 gives you a compile-time error for a path
expression that misuses an RTF?
The XSLT 1.0 spec is very unspecific about which errors are compile-time
errors and which are run-time. The spec merely says that this operation
"is not permitted". But you should be able to get it to compile by using
forwards-compatible mode, which you can invoke by setting version="2.0"
(or any value other than 1.0).
The rules for what a 2.0 processor should do when given a stylesheet
that says version="1.0" have not fully stabilised, but the next version
of the spec is likely to say that the processor should give a warning
about possible incompatibilities, and then execute the stylesheet in
backwards-compatible mode. It should not disallow use of 2.0 features
just because the stylesheet says version="1.0". In this case, however,
your stylesheet is using a 2.0 feature so it should say version="2.0".
Michael Kay
-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of
Julian Reschke
Sent: 18 August 2003 22:37
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: [xsl] advice on node-set fallback needed
Hi.
One of my stylesheets (rfc2629.xslt) internally requires an
RTF-to-nodeset conversion, thus I'm using the various
extension functions. Thanks to Exslt, the special cases have
been reduced to just two (Exslt and Msxsl). Until now, I was
using something like:
<xsl:choose>
<xsl:when test="function-available('exsl:node-set')">
<xsl:text>exsl: </xsl:text><xsl:value-of
select="name(exsl:node-set($test2)/node())" />
</xsl:when>
<xsl:when test="function-available('msxsl:node-set')">
<xsl:text>msxsl: </xsl:text><xsl:value-of
select="name(msxsl:node-set($test2)/node())" />
</xsl:when>
<xsl:otherwise>
<xsl:text>(none): </xsl:text><xsl:value-of
select="name($test2/node())" />
</xsl:otherwise>
</xsl:choose>
...hoping, that the <otherwise> case would only be reached (and thus
evaluated) on processors that do not support one of the two
extension functions, but may be allowing an implicit conversion.
However, this fails with MSXML4 -- the <otherwise> case is
compiled, although the xsl:value-of statement will never be reached.
Questions:
1) Is this a compliance issue in MSXML4? I think it is not,
because processors are allowed to evaluate in any order they
like (right?)
2) Does it make sense to even try a fallback? That is, will
an XSLT 2.0 processor executing a stylesheet marked as 1.0
allow the implicit conversion (understanding that in XSLT 2.0
it's not a conversion anymore)? And is there a way to write
the fallback in a way that is guaranteed not to cause a
compilation error by an XSLT 1.0 processor?
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list