> 
> 
> 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