Subject: RTFs are pointless (was node-set() function in MSXML?) From: "Evan Lenz" <elenz@xxxxxxxxxxx> Date: Fri, 4 Aug 2000 11:21:52 -0700 |
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@xxxxxxxxxxx http://www.xyzfind.com -----Original Message----- From: owner-xsl-list@xxxxxxxxxxxxxxxx [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Andrew Kimball Sent: Thursday, August 03, 2000 4:44 PM To: 'xsl-list@xxxxxxxxxxxxxxxx' 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: node-set() function in MSXML?, Andrew Kimball | Thread | XSL-List guidelines --changed, XSL-List Owner |
RE: XML to XML using IE5, Joshua Allen | Date | RE: Standard XPath expression for t, Ed Blachman |
Month |