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
<t:transform
version="1.1"
...
<t:document
Tobi
--
http://www.pinkjuice.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list