This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Which engine? (RE: JavaScript and XSL)


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]