David Carlisle wrote:
I don't need to
decide between a processor-specific extension,
Note that it's fairly easy to write multiple-output stylesheets that
work on a range of processors by using a named template that
uses an xsl:choose with element-available or an xsl:fallback
cascade that outputs the stuff using whatever is there.
I know, but that's why I wrote "[...] or do feature detection". I don't
want to do that, since it requires me to write 50 instead of one line.
see for example norm's version in the docbook sheets
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/docbook/xsl/html/chunker.xsl?rev=1.22&content-type=text/vnd.viewcvs-markup
which seems to have grown since last time I looked at it and now
<!-- This stylesheet works with XSLT implementations that support -->
<!-- exsl:document, saxon:output, or xalanredirect:write -->
This is exactly the kind of endless detection and workaround code I'm
happy to not have to write:
<xsl:choose>
<!-- put Saxon first to work around a bug in libxslt -->
<xsl:when test="element-available('saxon:output')">
<!-- Saxon doesn't make the chunks relative -->
<xsl:value-of select="concat($base.dir,$base.name)"/>
</xsl:when>
<xsl:when test="element-available('exsl:document')">
<!-- EXSL document does make the chunks relative, I think -->
...
Norm needs to support a wide selection of XSLT processors, so that's his
job, but I'm happy to not have to do that, and instead use a tiny
temporary solution and wait for XSLT 2.0. As I wrote.
Tobi
--
http://www.pinkjuice.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list