[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
RE: Which engine? (RE: JavaScript and XSL)
Subject: RE: Which engine? (RE: JavaScript and XSL) From: Andrew Kimball <akimball@xxxxxxxxxxxxx> Date: Tue, 24 Oct 2000 12:53:11 -0400 (EST) |
Back in March our team made the decision to eventually close the RTF querying loophole as a result of the thread quoted below, originally posted on the MSXML newsgroup. Because conformance was obviously so important to users, and because of Mike Kay's <xsl:if> case, I was convinced that I should close the RTF querying loophole (even though I strongly disagree with the spec on this point). Later, both Mike and I discovered independently that his <xsl:if> case was flawed, but I had already decided to be as conformant as possible (even in error cases such as this one). I delayed actually making this change until the September Beta release because of higher priority bugs and feature work, but I made no secret of my intention to close it before our release date (I've mentioned this intention several times on the MSXML newsgroup and the xsl-list in reply to questions on the subject). I certainly had no wish to "wrong-foot" Saxon. Rather, I'm making every effort to ensure that MSXSL is as conformant as possible. ~Andy Kimball MSXSL Dev From: akimball@xxxxxxxxxxxxx (Andrew Kimball) Date: Tue, 07 Mar 2000 02:54:25 GMT Subject: Re: Are multiple top elements allowed in params/vars? Newsgroups: microsoft.public.xml.msxml-webrelease > I can think of at least one pitfall with this: if X is a result tree > fragment, the test <xsl:if test="$X"> is currently defined as converting X > to a string and then to a boolean, which is subtly different from converting > it to a nodeset and then to a boolean. So if you guess which way the > standard is going to go, you'll be creating an awful mess for everyone if > you guess wrong. Seems unnecessary when the standard includes such > carefully-thought-out facilities for providing vendor extensions safely. You have a good case here. It frustrates me that the spec was kludged in this way (why??), but I don't want the output of ms-xsl to differ from other conformant processors. We'll rethink this decision for a future web release. Thanks for pointing this out. ~Andy Kimball MSXSL Dev From: "mhkay" <mhkay@xxxxxxxxxxxx> Subject: Re: Are multiple top elements allowed in params/vars? Date: Thu, 2 Mar 2000 23:39:21 -0000 Newsgroups: microsoft.public.xml.msxml-webrelease > Also, although the spec says that result tree fragments can only be used > with copy-of and converted to strings, msxsl allows more. Result tree > fragments are treated equivalently to a nodelist that contains a single > node (the root of the result tree fragment). This means they can be > queried. In my opinion, the spec seems arbitrarily limited on this point, > especially since querying into result tree fragments seems quite useful and > desirable. Therefore, our implementation doesn't bother to distinguish > between a result tree fragment and a nodelist (it would in fact be more > work to limit it in this way). Any feedback on this decision would be > appreciated. I can think of at least one pitfall with this: if X is a result tree fragment, the test <xsl:if test="$X"> is currently defined as converting X to a string and then to a boolean, which is subtly different from converting it to a nodeset and then to a boolean. So if you guess which way the standard is going to go, you'll be creating an awful mess for everyone if you guess wrong. Seems unnecessary when the standard includes such carefully-thought-out facilities for providing vendor extensions safely. Mike Kay Date: Thu, 02 Mar 2000 10:59:13 +0000 From: David Carlisle <davidc@xxxxxxxxx> Subject: Re: Are multiple top elements allowed in params/vars? Newsgroups: microsoft.public.xml.msxml-webrelease Andrew Kimball wrote: > Therefore, our implementation doesn't bother to distinguish > between a result tree fragment and a nodelist (it would in fact be more > work to limit it in this way). Any feedback on this decision would be > appreciated. > > ~Andy Kimball > MSXSL Dev I agree with you that the restrictions on result tree fragments are largely a mistake but _please_ don't allow invisible unflagged extensions to a published spec. If you had a flag internally that stopped result trees being queried, and then had a msxsl:node-set() function that did nothing but give you the argument back with queries allowed then you would be conformant to the spec and matching xt, saxon and xalan which offer exactly this functionality. At the same time you could lobby for this restricion to be dropped in xslt for some version > 1.0. That way a stylesheet starting with <xsl:stylesheet version="2.0" can use this feature and xslt 1.0 implementations can warn that somethings might not work, and the stylesheet can easily be written to work with existing XSLT 1.0 implementations, the majority of which do provide this feature via a node-set function. David From: akimball@xxxxxxxxxxxxx (Andrew Kimball) Date: Wed, 01 Mar 2000 19:45:11 GMT Subject: Re: Are multiple top elements allowed in params/vars? Newsgroups: microsoft.public.xml.msxml-webrelease A result tree fragment does not need to be a valid XML tree, with a single top-level document element. You can have multiple element/text/pi/comment children of the root node (the root node is implicitly created by msxsl). Also, although the spec says that result tree fragments can only be used with copy-of and converted to strings, msxsl allows more. Result tree fragments are treated equivalently to a nodelist that contains a single node (the root of the result tree fragment). This means they can be queried. In my opinion, the spec seems arbitrarily limited on this point, especially since querying into result tree fragments seems quite useful and desirable. Therefore, our implementation doesn't bother to distinguish between a result tree fragment and a nodelist (it would in fact be more work to limit it in this way). Any feedback on this decision would be appreciated. ~Andy Kimball MSXSL Dev XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Which engine? (RE: JavaScript a, Kay Michael | Thread | RE: Which engine? (RE: JavaScript a, Don Bruey |
RE: Error 80004005 eof - Microsoft , Andrew Kimball | Date | Re: need xsl for collapsed treeview, IRUDAYARAJ BACKIARAJ |
Month |