[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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

---

---

At 2010-04-13 08:15 -0400, Costello, Roger L. wrote:

Ken Holman wrote:

> 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.

Here are a couple answers:

1. I have a "gut feeling" that if I understand _why_ an XSLT document can be executed in parallel then it will help me write better XSLT documents.,

I think this particular feature is orthogonal to writing better XSLT.

Other features like tail recursion might lead one to "better" template design such as not having any reachable template content after a template call.

The feature of inferring a key for "//" is tricky because using it might be super fast on one processor and super slow on another processor.

2. I am trying to shift from an imperative mindset to a declarative mindset. I have always written XSLT in terms of sequential, step-by-step processing. The declarative mindset invites me to break out of that way of thinking, into a more parallel mode of thinking. I want to stop doing FORTRAN in XSLT. Understanding how things can be done in parallel will help me ... I think.

Well, when I think about it, my understanding is that results are assembled in the order the despatching was done that triggered the results.

That works regardless of the implementation being serial or parallel. In a serial system the despatch of the following item isn't done until the results of the preceding item are completed. In a parallel system the despatch of items might happen faster than the results for each despatch are produced, but the results are assembled in the order despatched.

But a system implementing parallelism will get similar results if I do:

 <result>
  <xsl:apply-templates select="abc,def"/>
 </result>

or

 <result>
  <xsl:apply-templates select="abc"/>
  <xsl:apply-templates select="def"/>
 </result>

or

 <result>
  <xsl:for-each select="abc">
   ...
  </xsl:for-each>
  <xsl:for-each select="def">
   ...
  </xsl:for-each>
 </result>

One might think when first looking at the last one that it is serial and not parallel. But that isn't true because during the processing of any XML element (in the example above <result>) all children of that element can be despatched in child order but processed in parallel provided the results of each child's processing are assembled in the child order. Thus both <xsl:for-each> instructions could be processed in parallel.

The hierarchy of XML *inherently* promotes parallelism. At *every* element.

The XQuery/XSLT language design promotes parallelism by not interfering with the process-in-any-order-and-assemble-in-despatched-order nature of XML.

*Other* languages that are not functional side-effect-free languages introduce features programmers want to use and like to use that totally interfere with that. They have no idea of how they are hobbling themselves just in the name of convenience or laziness of using things like global variables that vary. They refuse to even consider learning the elegance of XSLT or XQuery in favour of what they already know.

The XSLT/XQuery language designers recognized the importance of not interfering with the inherent parallelism of XML, thus leaving the door open for massively-parallel processing of XML documents using these languages. I can't wait to see some vendor support this. Any XML processing language without these features will be left in the dust.

Until such a massively-parallel system is built, executing the scripts serially still works! That is one aspect of the elegance of it. As a stylesheet writer, I won't have to care.

I hope this helps.

. . . . . . . . . . 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

---