Actually the database handles the 'how many' and 'which' xml docs to
transform - which is way the solution had to be scalable to n. I just got
done building the prototype with the excellent code Lars posted earlier.
Alan
On 5/13/03 11:05 AM, "Passin, Tom" <tpassin(_at_)mitretek(_dot_)org> wrote:
It depends on how you are supposed to know which xml pieces to
concatenate. Assuming there is some way to know that beforehand, I
would create a driver file and run the transform against it instead.
Something like this -
driver.xml
<pieces>
<piece src='file:///piece1.xml'/>
<piece src='file:///piece2.xml'/>
...
</pieces>
aggregate.xsl
<xsl:stylesheet .....>
<xsl:template match='/pieces'>
<wrapper-element>
<xsl:for-each select='piece'>
<xsl:copy-of select='document(@src)'/>
</xsl:for-each>
</wrapper-element>
</xsl:template>
</xsl:stylesheet>
This is simple and easy to maintain, and very clear as to what it is
doing.
Cheers,
Tom P
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list