Re: [xsl] N : M transformation

[Tobias Reif <tobiasreif@xxxxxxxxxxxxx>]

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