Abel,
Thanks for the very nicely composed explanation for Simon. One of the
best things about this list is how explanations are provided that can
be followed by people who don't themselves have any need for a
particular solution, but who can still learn valuable lessons and
techniques from the sidelines. It's one of the best ways of learning.
I would, however, quarrel with one aspect of your description. You
have the code:
<xsl:template match="/">
<!-- mini pipeline: put points into a variable and process them -->
<xsl:variable name="points">
<xsl:apply-templates select="root/set[1]/point[1]"
mode="aggregate">
<xsl:with-param name="calc" tunnel="yes">
<for x="1" y2="2" y3="2"/>
</xsl:with-param>
</xsl:apply-templates>
</xsl:variable>
<!-- apply set with pre-processed points -->
<xsl:apply-templates select="root/set">
<xsl:with-param name="points" select="$points" />
</xsl:apply-templates>
</xsl:template>
... which you refer to as using a "micro-pipeline".
As I explained earlier this week, I don't believe this is a
micro-pipeline, since it operates globally. The declaration of
$points could appear outside the template and it would perform the
same way. A micro-pipeline would be if you bound a variable in a
template you expected to fire more than once, and then processed the
results of that variable. Admittedly there may be a grey zone between
a pipeline operating at the document (global) level, and one that
operates at a more local level; but I believe this falls fairly
clearly into the first category.
(Then too, as you also explain, you don't really run a pipeline here
at all, but use the results of pre-processing as a lookup table.)
The reason I stress this is because I'm afraid that if we start
calling anything a micro-pipeline just because it involves some
matching and applying of templates whose results won't appear in the
output, then we'll have to invent a new word for what we actually
invented the term for.
The more general technique, I'd say, is called "pipelining", or -- if
the results are themselves not processed directly (this includes
generating lookup tables) "pre-processing". Another interesting thing
to reflect on is that pipelining and pre-processing can be achieved
in XSLT 1.0 by passing the results of one stylesheet into another as
its source. This really isn't practical with micro-pipelining, which
happens only within the scope of a single branch of the tree at a time.
I apologize if this comes across as rude. Another valuable thing we
do on this list is guard one another's terminology. ("Don't call them
tags", etc.) This keeps the language strong because we have
unambiguous terms to refer to things, methods and techniques, which
can then be discussed and learned about.
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================