This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Which engine? (RE: JavaScript and XSL)
- To: "'xsl-list at mulberrytech dot com'" <xsl-list at mulberrytech dot com>
- Subject: RE: Which engine? (RE: JavaScript and XSL)
- From: Andrew Kimball <akimball at microsoft dot com>
- Date: Tue, 24 Oct 2000 12:53:11 -0400 (EST)
- Reply-To: xsl-list at mulberrytech dot com
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@microsoft.com (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@iclway.co.uk>
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@nag.co.uk>
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@microsoft.com (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