[Fwd: Re: [xsl] xsl:script and side-effects]

Forwarded for archiving.

-------- Original Message --------
Subject: Re: [xsl] xsl:script and side-effects
Date: Thu, 15 Feb 2001 19:49:37 -0800
From: Joe English <jenglish@flightlab.com>
Reply-To: xsl-list@lists.mulberrytech.com
To: xsl-list@lists.mulberrytech.com


Earlier, I wrote:

> > The introduction of <xsl:script> raises the possibility
> > that evaluating an XPATH expression may produce side-effects.

To which both Michael Kay and David Carlisle replied
[quoting Mike, but David said almost exactly the same thing]:

> No, that possibility was introduced by XSLT 1.0 when it allowed for
> extension functions.

Hm.

Let me try again:

Suppose I wanted to implement a strictly conforming XSLT 1.1 processor
which implements the officially-sanctioned Java bindings in C.4.

Users should be able to rely on the guarantee that, if they
avoid features explicitly labelled as implementation-dependent
in the XPATH and XSLT specs, then their stylesheets will work
the same way with my implementation as they do with, say,
Saxon (it goes without saying that Saxon implements the spec
correctly :-)

My problem as a hypothetical implementor is: how do I ensure
that this guarantee is met?

With XSLT 1.0 this isn't an issue: the only way side-effects
can happen is if I add a vendor extension that produces them (in
which case it would be my responsibility to document their semantics).
With XSLT 1.1 + Java bindings though, users can introduce their
*own* side-effecting operations, and the XSLT Recommendation doesn't
tell me (as a hypothetical XSLT implementor) *anything* about when
or if they should be applied.

So we can end up with strictly conforming stylesheets that behave
differently -- perhaps radically differently! -- with two different
strictly conforming XSLT implementations.

This is a hole in the spec that ought to be patched.

(I'd prefer that it be patched by adding a brief note stating that
the order of side-effects in user-supplied extension functions is
implementation-dependent.  Alternately, the XSL WG could provide a
normative operational semantics for XSLT, but I think the brief
note would be a better solution.)


--Joe English

  jenglish@flightlab.com

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

Received on Thursday, 15 February 2001 23:18:05 UTC