The easiest way to solve this is to restructure the XML, if
possible. Then your input could look like this:
<root>
<europe>
<store location="london">
<staff>100</staff>
</store>
<store location="paris">
<staff>50</staff>
</store>
<store location="madrid">
<staff>25</staff>
</store>
</europe>
<north-america>
<store location="new york">
<staff>200</staff>
</store>
</north-america>
<asia>
<store location="tokyo">
<staff>125</staff>
</store>
</asia>
</root>
And summing any particular group is easy the the XLST sum() function:
<xsl:template match="/root">
<xsl:variable name ="staffing" select="sum(europe/store/staff)" />
<xsl:value-of select="$staffing" />
</xsl:template>
If you can't get the producer of the XML to group the data
like this, we'll have to try another approach.
Excellent suggestion, thanks Charles. However, I fear that
my example XML may not have illustrated my problem fully.
This has made me think about the structuring though.
In my real application, the sub-elements are accounts with
account numbers as the attribute. Different users will be set
up to view different sets of accounts and these may intersect/overlap
- which potentially breaks the organisation solution you proposed.
I guess my original query was "can functions like SUM() be parameterised
from a list?".
I imagined I would have to create a sub set into an xsl:variable and
then
use that. Or something.
In the end I think I've decided to do this filtering upstream since
I do create the XML myself. This just means that the user-specific
XML document has to be created for each request - I did intend caching
the full XML document (as a dom4j Java object in my Tomcat server)
and then "picking out" the bits for each user.
Many thanks to all who replied to my posting.
Best regards,
Chris
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list