Re: N : M transformation
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.
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
<t:transform version="1.1" ... <t:document
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format