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
Saxonica
On 10/03/2011 18:28, Andrew Welch wrote:
Hi,
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)"/>
</xsl:for-each>
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
up:
<xsl:appender name="someAppender" option1="foo" option2="bar"/>
with:
<xsl:append name="someAppender"> text to append</xsl:append>
and then to access it:
get-appender('someAppender')
--~------------------------------------------------------------------
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>
--~--