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

Re: [xsl] N : M transformation

---

---

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

---