This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: xsl:script and side-effects
- To: "'xsl-list at lists dot mulberrytech dot com'" <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] xsl:script and side-effects
- From: "Kaganovich, Yevgeniy (Eugene)" <ykaganovich at netfish dot com>
- Date: Thu, 15 Feb 2001 21:15:44 -0800
- Reply-To: xsl-list at lists dot mulberrytech dot com
: 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