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

[xsl] What todo when execution order becomes important? I.e.: with text data and filters


Subject: [xsl] What todo when execution order becomes important? I.e.: with text data and filters
From: Abel Braaksma <abel.online@xxxxxxxxx>
Date: Tue, 19 Dec 2006 21:55:35 +0100

Dear List,

I think I understand a little bit of the parallel execution benefits of xslt processor and the related execution order which one cannot influence in any way. I also know that it is guaranteed that the input source tree follows the same order as the output source tree in some way. This all works perfectly well in practice. Until today....

Now, when using a temporary result tree (if I got the name correctly) from a variable, and I need to parse its nodes, yet the content of these nodes will *not* become part of the result document, then, if the order *is* important because the order influences the final result tree, how can I get the processor to follow my order? I've got no clue.

The use-case here is: a chained filter. Where the filter is supplied as node set to a root variable in XSLT. These filters are then applied recursively to the the input document, which happens to be a text document. Sometimes, Saxon appears to follow the input order, but more often than not, it doesn't. I found out by using xsl:message.

How can I change my design so that it actually processes the nodes of a variable in the order that I give him? I hoped that the "following-sibling" instruction, plus the correct inclusion of the recursive-ness would do the trick here.... apparently not :S . Any ideas are welcome.

Here's a sample (simplified, this way it may make little sense for the chosen approach, but I didn't want to bug you with pages of xslt).

Result if filters are executed in order: 'string with some data'
Result if filters executed out of order (depends): 'string zysith some daasa' (note the 's')
Note that it may be required to put more filters in place or to make the input more complex so that the processor actually decides to mix the order of execution due for efficiency.


<xsl:call-template name="apply-filter" select=" ' string xyzith zzzzome daaza' " />

<xsl:variable name="filter">
   <filter find="aaz" replace="t" />
   <filter find="xyz" replace="w" />
   <filter find="z+" replace="s" />
</xsl:variable>


<xsl:template name="apply-filter" xpath-default-namespace="">
<xsl:param name="value" />
<xsl:param name="filter" />
<xsl:variable name="single-filter-result">
<xsl:analyze-string select="$value" regex='{$filter/@find}'>
<xsl:matching-substring>
<xsl:value-of select="replace(., $filter/@replace)" />
</xsl:matching-substring>
<xsl:non-matching-substring>
<xsl:value-of select="." />
</xsl:non-matching-substring>
</xsl:analyze-string> </xsl:variable>
<xsl:variable name="multi-filter-result">
<xsl:choose>
<xsl:when test="$filter/following-sibling::filter">
<xsl:call-template name="apply-filter">
<xsl:with-param name="value" select="$single-filter-result" />
<xsl:with-param name="filter" select="$filter/following-sibling::filter[1]" />
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$single-filter-result" />
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:value-of select="$multi-filter-result" />
</xsl:template>



Current Thread
Keywords