[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] advice on node-set fallback needed


Subject: RE: [xsl] advice on node-set fallback needed
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Tue, 19 Aug 2003 08:37:05 +0100

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@xxxxxxxxxxxxxxxxxxxxxx 
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Julian Reschke
> Sent: 18 August 2003 22:37
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> 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



Current Thread
Keywords