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(_at_)CraneSoftwrights(_dot_)com
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--