Saxon

Legacy ID: #7429065 Legacy Poster: Michael Kay (mhkay)

I'm confused. If you don't want to use xsl:result-document to output multiple documents, how else would you expect to do it? You can indirect the output of xsl:result-document using an OutputURIResolver. This interface isn't exposed directly in s9api, but you can use it by dropping down into lower level interfaces.

Legacy ID: #7429068 Legacy Poster: David Lee (daldei)

Another way would be to run multiple transformations on the same file. Parse/load the document once, then run multiple S9API transformations (each a different stylesheet) going to a different output.

Legacy ID: #7429073 Legacy Poster: Kevin (weslowsk)

I don't want to use the xsl tag embedded technique of outputting multiple documents because I'd like to use the API to do it. One reason is I'd like more control, like from the API, over how error handling occurs when, say, the xsl:result-document href corresponds to a invalid location. I think the default that happens right now is that the error gets sent to System.err, but I'd like to add to that functionality by, say, emailing someone when that happens. Here's an example of what my source XML would look like: <abc> <def>1</def> <def>2</def> <def>3</def> </abc> I was thinking something along the lines of I could query using XPath, and find each <def> nodes, loop through (3 times), and then assign each node found as the initial context node for the transformer: transformer.setInitialContextNode(node); and then set each transformer destination as a different file: transformer.setDestination( ... ); but I need some guidance if this is do-able or just a crazy idea that doesn't make sense? I'll read up on the OutputURIResolver in the meantime... thanks... Kevin

Legacy ID: #7429085 Legacy Poster: Michael Kay (mhkay)

It's certainly possible to run multiple transformations, one to produce each output file (you can use the same XsltTransformer with different parameters or a different initial context node). But running one transformation with multiple outputs is likely to be more efficient in most cases, I would have thought. It's also likely to be much more convenient in those cases where the number of result documents is variable depending on what you find in the input document, for example when splitting a book into chapters.

Legacy ID: #7429089 Legacy Poster: Kevin (weslowsk)

I agree, efficiency is on the side of 1 transformation. I do have a variable number of result documents, so this may become an issue...thanks, Michael, that's good to know. Anyway, I'll try the suggestion and see if I can put together a proof of concept application...I welcome any samples if anyone is faster than me at putting this together! :) thanks for all the quick replies! Kevin

Legacy ID: #7429126 Legacy Poster: David Lee (daldei)

Its not crazy. It may not be as efficient as doing everything in xslt directly but its a common problem/solution. It may not be ideal but you may want to consider a scripting language like "xmlsh" (www.xmlsh.org) for this type of thing. Its what it was designed for. Its not as efficient as doing everything in xslt but its not that bad either and a lot easier to prototype then hand java. xmlsh script to do what your looking for ( simplified but not unrealistic ) ---- xread doc < doc.xml for i in <[ $doc//def ]]> ; do xslt -f script.xsl -i $i || { echo Script failed | mailx -s "Failed" user@domain.com ; } done ---- This isnt as inefficient as it looks, xmlsh runs within the same JVM as saxon so this is done about as efficiently as hand-coded java code. The document is read into a saxon "tiny tree" once, xpath (actually xquery) is run to produce each sub-node and xslt is run with the context of that node as its root.

Legacy ID: #7429151 Legacy Poster: Kevin (weslowsk)

cool, thanks, I'll take a look at setting up xmlsh...