Re: Relying on the orser of excution is harmful (Was:

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