RE: xsl:script and side-effects

: 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.

Wow,

If I understand Joe's point correctly, the problem is that it's impossible
to define standard binding for ANY procedural language because order of
executing the extensions becomes important, and it is against XSLT's
declarative nature to mandate conformance to a specific order of execution! 

I suppose a binding *could* enforce order of execution if you want your
processor to be compliant with respect to that binding, but this feels like
a BAD thing to do...

It's probably better to define bindings to be side-effect free, and let
extensions developers worry about side-effect issues per implementation (as
long as they are aware of the issue).

- Eugene

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