[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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] advice on node-set fallback n, Julian Reschke | Thread | RE: [xsl] advice on node-set fallba, Julian Reschke |
Re: [xsl] Bread-crumbs nav from nes, Armen Martirossian | Date | RE: [xsl] How can I get XSLT to wri, Michael Kay |
Month |
Keywords