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

[xsl] advice on node-set fallback needed


Subject: [xsl] advice on node-set fallback needed
From: "Julian Reschke" <julian.reschke@xxxxxx>
Date: Mon, 18 Aug 2003 23:37:23 +0200

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



Current Thread
Keywords