RTFs are pointless (was node-set() function in MSXML?)

["Evan Lenz" <elenz at xyzfind dot com>]

Instead of using the crude (and potentially unreliable)
contains(system-property('xsl:vendor'),'Microsoft'), a better approach to
portability might be to use function-available('ms:node-set').  That's the
approach Michael Kay uses on page 461-462, where he also speculates that
version 2.0 of XSLT will have a node-set() function.

Again I ask, in the new version of XSLT, why not just scrap the need for a
function altogether (as MSXML currently does)?  There seems to be no concern
over backwards compatibility.  On result tree fragments, version 1.0
stylesheets may implement only a subset of the permitted operations on
node-sets.  If XSLT 2.0 permits *all* of them, there certainly shouldn't be
a problem using only a subset of them.  An XSLT 2.0 processor would thus be
"non-compliant" with XSLT 1.0 only in the sense that Mike says MSXML is
non-compliant (w.r.t. RTFs).  As far as forwards compatibility goes, it's
true that element-available(), function-available(), and <xsl:fallback>
would not be of help in this case, but system-property('xsl:version') would
do the trick.

I'm still operating under the assumption, especially after reading Mike's
admission that RTFs always evaluate to true, that there should be no
practical difference between treating an RTF as a node-set with a function
or without a function.  Why was there ever even such a thing as an RTF??
Couldn't we have been fine with just the four XPath datatypes?  If anyone
wants to take the burden of answering this challenge, feel free.

Thanks,

Evan Lenz
elenz@xyzfind.com
http://www.xyzfind.com


-----Original Message-----
From: owner-xsl-list@mulberrytech.com
[mailto:owner-xsl-list@mulberrytech.com]On Behalf Of Andrew Kimball
Sent: Thursday, August 03, 2000 4:44 PM
To: 'xsl-list@mulberrytech.com'
Subject: RE: node-set() function in MSXML?


Mike Kay wrote:
> I believe this non-compliance in MSXML is merely that it processes
something
> which the spec says it must report as an error: it doesn't cause any
correct
> stylesheets to behave differently from the way the spec says they should.
So
> the only real portability impact is that a stylesheet that "works" on
MSXML
> won't port to something else.

Another problem exists with this syntax: conformant processors might flag
"$x/foo" as an error at compile-time (I don't know if any currently do).  If
"msxsl:node-set($x)/foo" is used instead, then other processors will only
give a runtime error if that statement is executed (not allowed to throw
compile-time error).  This makes it possible to write a stylesheet that
switches on "xsl:vendor" and uses the node-set function particular to a
particular vendor.

~Andy Kimball
MSXSL Dev


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list