[xsl] Re: xslt 3.0 possible feature - some sort of collection to help when streaming

Subject: [xsl] Re: xslt 3.0 possible feature - some sort of collection to help when streaming
From: "Vladimir Nesterovsky" <vladimir@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 11 Mar 2011 09:08:28 +0200
xsl:iterate works but it's limited to a single level of iteration, as
this way one cannot easily collect output from nested transformations.

I read Andrew Welch's request as a wish to have
a way to produce multiple intermediate outputs at once.

Indeed, during transformation you can consume many (intermediate) inputs.
It would be symmetric to expect multiple (intermediate) outputs.
Vladimir Nesterovsky

The approach in the spec to this kind of requirement is the xsl:iterate instruction. Instead of using xsl:message to output the data that you want to process at the end, you append it to a sequence which is passed as a parameter to each iteration of xsl:iterate, and it's then available for processing at the end using xsl:on-completion. We're adding support for maps to the language with this use case very much in mind; it makes it easier to accumulate more complex data on your single streamed pass through the input.

Michael Kay

On 10/03/2011 18:28, Andrew Welch wrote:

Often we 'hack' xsl:message to output some information to post process
later, and it struck me that it would be useful to have a way of
accessing what has been sent to xsl:message during the same transform.
  This would be especially useful when streaming, as processing the
data twice for different purposes is less than ideal.

For example, you for-each over some data but want to also do something
with @names later:

<xsl:for-each select="/millions/and/millions">

[ process each item ]

   <xsl:message select="concat('Processed ', @name)"/>

then later in the same template, say to create an index or list of links:

<xsl:for-each select="get-messages()">
[ process the items stored earlier 'Processed name1' , 'Processed name2' etc ]

Is there anything conceptually wrong with this, other than the
non-guaranteed order of processing?  If not, then it could be a proper
instruction rather than xsl:message, eg a top-level element to set it

<xsl:appender name="someAppender" option1="foo" option2="bar"/>


<xsl:append name="someAppender"> text to append</xsl:append>

and then to access it:


Current Thread