I think I've already posted my thoughts to the list. At some time before shipping the stylesheet to the client, run it through another stylesheet which finds the xsl:include directives, extracts their specified URIs, and uses xsl's document() function to replace the includes with the contents of the included file. Should be easy to write.
I don't think you "lose" anything by doing so. xsl:include is pretty straightforward. xsl:import, on the other hand, would require more logic. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html) From: Arnaud Diederen <arnaud.diede...@erdas.com> To: kesh...@us.ibm.com Cc: xalan-j-users@xml.apache.org Date: 08/04/2010 10:11 AM Subject: Re: Serializing a (composed) XSL Joseph, would you have any further thought on this? Thanks, A. On Tue, 2010-08-03 at 16:35 +0200, Arnaud Diederen wrote: Joseph, On Tue, 2010-08-03 at 08:59 -0400, kesh...@us.ibm.com wrote: Why not use a stylesheet to style your stylesheet and bring the includes into a single document, rather than trying to work with Xalan's low-level data structures (which weren't really designed to be written back out as XSL)? If I understand your suggestion correctly, what I should implement is some sort of mechanism that will "replace" xsl:include directives with the contents of the document they reference. Is that correct? If that's the case then it's just some sort of query-replace, and I lose the benefits of using an XSL processor, such as: namespace/prefix resolution, etc... Am I missing something? A. I admit I may be biased -- I wrote the "styling stylesheets" article on IBM's XML Developerworks page (http://www.ibm.com/xml) -- but this really does strike me as being both much easier and more portable. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html) From: Arnaud Diederen <arnaud.diede...@erdas.com> To: xalan-j-users@xml.apache.org Date: 08/03/2010 08:47 AM Subject: Serializing a (composed) XSL Gentlemen, I have a web application that uses, on the browser-side, XSL transforms. Alas, because of a little issue in WebKit (affecting Google Chrome, Safari, ...), I cannot use composed XSLTs (i.e., XSLs that <xsl:include>s other bits of XSL) in Chrome. I thought I'd give xalan-java a try at solving my problem, by "composing" the XSLT bits into one big XSL, on the server-side. That composed XSL could then be used by all browsers. Here's what I had in mind: * get xalan-java to load the XSL. * get xalan-java to load its children. * dump the composed XSL as String, or byte []. And here's my first attempt at this task: TransformerFactory tFactory = TransformerFactory.newInstance(); Transformer transformer = tFactory.newTransformer (new StreamSource("/path/to/xslt/common.xslt")); TransformerImpl transformerImpl = (TransformerImpl) transformer; StylesheetRoot stylesheetRoot = transformerImpl.getStylesheet(); stylesheetRoot.recompose(); Document stylesheetDoc = stylesheetRoot.getOwnerDocument(); W3CNodeHelper nodeHelper = new W3CNodeHelper(); String out = nodeHelper.dumpAsString(stylesheetDoc.getChildNodes().item(0)); (Where the "W3CNodeHelper" thingy is just one of our tools I use to dump the document.) Unfortunately this fails, as: java.lang.RuntimeException: ElemTemplateElement error: Function not supported! at org.apache.xalan.templates.ElemTemplateElement.error(ElemTemplateElement.java:223) at org.apache.xalan.templates.ElemTemplateElement.error(ElemTemplateElement.java:236) at org.apache.xml.utils.UnImplNode.getAttributes(UnImplNode.java:641) at com.ionicsoft.xml.dom.W3CNodeHelper.dumpElement(W3CNodeHelper.java:992) at com.ionicsoft.xml.dom.W3CNodeHelper.dump(W3CNodeHelper.java:851) at com.ionicsoft.xml.dom.W3CNodeHelper.dump(W3CNodeHelper.java:825) at com.ionicsoft.xml.dom.W3CNodeHelper.dumpAsString(W3CNodeHelper.java:802) at com.Test.main(Test.java:43) I guess this method is far from ideal. Would anyone have any information on how I could achieve what I'm trying to? Thanks a bunch for any info/pointer! Regards, A.