Subject: Re: [xsl] Relying on the orser of excution is harmful (Was: Re: XSL Help!!) From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx> Date: Fri, 06 Dec 2002 10:37:48 -0500 |
I suppose one way of making sure extension functions are called in a certain sequence would be to wrap them in xsl:variable/@select statements and then make sure the variable is used in the next call to an extension function that depends on the previous call. Right? This works nicely with Java APIs that return the main object even for methods that could just as well return void (and unfortunately most of them do...)
<xsl:variable xmlns:e="java:my.Gizmo" name="gizmo" select="e:new()"/>
<xsl:variable xmlns:e="java:my.Gizmo" name="configured-gizmo" select="e:configure($gizmo, ...)"/>
<xsl:variable xmlns:e="java:my.Gizmo" name="energized-gizmo" select="e:energize($configured-gizmo, ...)"/>
? May be what would be nice was if the Java extension function proxy would automatically return the object itself in case that the method returns void. There isn't really much use for a void value anyway.... Or may be the function proxy would allow trailing void values in an actual argument list to indicate dependencies that remain without value. So I could say:
<xsl:variable xmlns:e="java:my.Gizmo" name="gizmo" select="e:new()"/>
<xsl:variable xmlns:e="java:my.Gizmo" name="ensure-gizmo-configured" select="e:configure($gizmo, ...)"/>
<xsl:variable xmlns:e="java:my.Gizmo" name="energized-gizmo" select="e:energize($gizmo, ..., $ensure-gizmo-configured)"/>
It is also courious that while XSLT retracts much of the control flow implications of a sequence of nodes, it still requires a variable node to occur before that variable is referenced. It's not unreasonable to require that for both readability and simple processing reasons, but it might convey the wrong impression to the casual XSLT programmer.
regards, -Gunther
Having these two instructions in that order:
<xsl:apply-templates select="NAME"/> <xsl:apply-templates select="Phone[@type='work']"/>
does not guarantee at all that the appropriate templates will be applied on the "NAME" children before the appropriate templates will be applied on the "Phone[@type='work']" children.
They may be applied in any order or in parallel and this is one of the reasons why relying on the order of calling extension functions often produces unpredictable results.
The only guarantee is that when the output tree is constructed, the output of the first xsl instruction will precede the output of the second. However, this doesn't at all affect the many different possible ways how these will be executed in the course of time.
The XSLT spec explains the processing model first sequentially and then
says:
"Implementations are free to process the source document in any way that produces the same result as if it were processed using this processing model."
http://www.w3.org/TR/xslt#section-Processing-Model
A good example that one must not rely on "order of execution" can be found here:
http://groups.google.com/groups?hl=de&frame=right&th=418985883ecc2e2c&seekm=uZk9iKYiBHA.2000%40tkmsftngp04#link1
This touches another topic -- the harm of uncontrolled use of extension functions (with side effects) in a functional programming language.
There are ways to control the order of execution, but placing two xsl instructions one after the other is not one of these ways.
-- Gunther Schadow, M.D., Ph.D. gschadow@xxxxxxxxxxxxxxx Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistant Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Relying on the orser of excut, Dimitre Novatchev | Thread | Re: [xsl] Relying on the orser of e, Dimitre Novatchev |
Re: [xsl] Problems using java exten, Gunther Schadow | Date | RE: [xsl] Locating Things Relative , bryan |
Month |