Subject: RE: [xsl] xsl:script and side-effects From: "Kaganovich, Yevgeniy (Eugene)" <ykaganovich@xxxxxxxxxxx> Date: Thu, 15 Feb 2001 21:15:44 -0800 |
: 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] xsl:script and side-effec, Michael Kay | Thread | [xsl] Cropping results - count( ) q, mjyoungblut |
Re: [xsl] XSLT 1.1 comments, Uche Ogbuji | Date | RE: [xsl] XSLT 1.1 comments, Kaganovich, Yevgeniy |
Month |