RE: [xsl] The output of evaluating an XSLT transform is the same regardless of the order in which output elements are evaluated. Right?

["G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>]

At 2010-04-13 07:33 -0400, Costello, Roger L. wrote:
> Yesterday I wrote:
>
> >> Is this statement true or false:
> >>
> >>   XSLT elements that produce output can be
> >>   evaluated in any order.
>
> Michael Kay responded:
>
> > Well, your terminology is wrong. I guess you are referring to XSLT
> > instructions; they don't "produce output", they are evaluated to return a
> > result value.
>
> Hi Michael, I carefully avoided using the word "instruction" or 
> "statement" because on March 24 on the xml-dev list you wrote:
>
>    Declarative programming doesn't use "statements" or
>    "instructions". It describes the relationship of the output to the input.
>
> QUESTION #1
>
> Why do you now say "XSLT instructions"?

From the introduction of the first edition of XSLT:

  http://www.w3.org/TR/1999/REC-xslt-19991116#section-Introduction
  "A template can contain elements that specify literal result element
   structure. A template can also contain elements from the XSLT
   namespace that are instructions for creating result tree fragments."

> QUESTION #2
>
> Michael, I think that I read this in your latest book (around page 
> 930, I think):
>
>    The elements in an XSLT document can be executed in any order, 
> even in parallel.
>
> Yesterday I thought that I had it all figured out: the in-memory 
> result tree can be constructed in any order, even in parallel. 
> However, from yesterday's responses, I am more confused than before. 
> Would you (or anyone) please explain how the elements in an XSLT 
> document can be executed in any order, even in parallel?

I'm curious:  why is the "how" important?  I work with these 
technologies every day and I don't care *how* the processor fulfills 
the spec, as long as the spec is fulfilled.  A stylesheet writer's 
responsibility is to understand how the specification works.

If a particular vendor offers parallelism on a multi-processor system 
and I get my results faster using that vendor's tool than another 
vendor's tool, I'll consider that in my tool selection.

Are you not asking the vendors on the list to reveal the inner 
workings of their products?

Granted, knowing that one processor supports tail recursion or that 
another processor infers key tables for certain addresses or that 
parallelism is supported for a multi-processor system or whatever are 
all distinguishing implementation features that vendors can use to 
make their conforming interpretation of the specification "better" or 
faster.  So they might advertise such product differentiation 
features in order to compete.  But to reveal the inner workings?

How will the answer from any vendor to this particular question of 
yours change the way you write your stylesheets?

. . . . . . . . . . . . . Ken

--
XSLT/XQuery training:         San Carlos, California 2010-04-26/30
Principles of XSLT for XQuery Writers: San Francisco,CA 2010-05-03
XSLT/XQuery training:                 Ottawa, Canada 2010-05-10/14
XSLT/XQuery/UBL/Code List training: Trondheim,Norway 2010-06-02/11
Vote for your XML training:   http://www.CraneSoftwrights.com/s/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal