Re: [xsl] N : M transformation

Subject: Re: [xsl] N : M transformation
From: Tobias Reif <tobiasreif@xxxxxxxxxxxxx>
Date: Mon, 03 Feb 2003 17:53:27 +0100
David Carlisle wrote:

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.

only once though. Once you have a named template set up that's doing the
fallback then it's just a matter of doing [...]

I guess it also boils down to attitude/philosophy, and to different sets of requirements per scenario.

If I rely on a draft, and wait for a standard (rec), then rely on standards, I automatically support any XSLT processor; first in a shaky way (draft), then in a stable way.

If there's no absolute (commercial or the like) requirement to support the most popular XSLT processors with all their quirks, then I'm happy that I don't have to write endless detection and workaround code. I say endless, because if I detect five processsors, then there'll be a sixth, etc. This kind of redundancy very much goes against my taste, so that I rather simply read the XSLT specs and not each processor's documentation, and rely on one line of processor-independent code based on a draft, instead of hunting down each and every quirk of an arbitrary number of implementations ("Saxon doesn't make the chunks relative", "put Saxon first to work around a bug in libxslt" etc etc).

But copying Norm's detection block and going with your

<xsl:call-template name="write-document">
  <xsl:with-param name="href" select="'kjhgkg'"/>...

sure is a good workaround until XSLT 2.0 is here, for those who have to do feature detection.

Anyways, the lack of support for multiple output documents in XSLT 1.0 leaves us all in a situation where one workaround is +/- as bad as the other, so luckily, XSLT 2.0 is not far away.

(It gets worse the more attrubute of saxon:output that you used,

None; I currently use




XSL-List info and archive:

Current Thread