Re: Feeding DOMs to XSLT Processors
Scott, Thank you for the help. Paul Levin's instructions (below) got me where I need to be right now. > As far as non-public pre- and/or post-processing logic that isn't all > publicly accessible, let us know what you mean specifically, and > we'll work > with you on this. It looks like I was mistaken. I apologize. I was starting with the main() method in the transform.java file and working backwards to figure out what to do. This obviously didn't work. Maybe placing Paul's instructions in the Xalan documentation would be something to consider -- because while the functionality (API) was available for accomplishing my goal, it wasn't readily apparent. Or maybe it was just a shortcoming on my part. Paul's post is below: > Date: Thu, 03 Feb 2000 13:27:20 -0500 > From: Paul Levin <plevin@xxxxxxx> > Subject: Re: Feeding DOMs to XSLT Processors > > Mike, > Using Xerces (XML DOM implementation and parser) and Xalan (XSLT) > you > do the following: > > 1) build your DOM using methods in org.apache.xerces.dom.DocumentImpl. > 2) compile your XSL stylesheet, from a file, into a > org.apache.xalan.xslt.StylesheetRoot, using > org.apache.xalan.xslt.XSLTEngineImpl.processStylesheet(). Be sure to > construct the XSLTEngineImpl with an > org.apache.xalan.xpath.xdom.XercesLiaison. > 3) apply the StylesheetRoot to the DOM using > org.apache.xalan.xslt.StylesheetRoot.process(). > 4) the result of process() is another DOM. If your stylesheet generated > HTML then this DOM has HTML nodes. process() has the ability to render > this DOM, or you use some other xalan class to render this DOM to text. (I > do not know the name of this class off-hand, because I needed to write my > own renderer, since I output something other than XML, HTML and TEXT.) > Paul Thanks. Mike.... --- Scott Boag/CAM/Lotus <Scott_Boag@xxxxxxxxx> wrote: > > > Xalan and XT appear to use > > standard DOMs, but we'll have to modify the source classes a little > > because their pre- and/or post-processing logic isn't all publicly > > accessible. > > For Xalan, if you set up the processor with the > XMLParserLiaisonDefault, > you can access a generic DOM. There are complications if you do this > and > you need to use the Documeng() function, or xsl:include, or the like. > You > can fix this by deriving an object from XMLParserLiaisonDefault and > implementing the parse method. > > As far as non-public pre- and/or post-processing logic that isn't all > publicly accessible, let us know what you mean specifically, and > we'll work > with you on this. > > -scott > > > > > > > Michael Harry > > Scepaniak To: > xsl-list@xxxxxxxxxxxxxxxx > <ihispanic@xxxxxxxxx> cc: (bcc: Scott > Boag/CAM/Lotus) > Sent by: Subject: Feeding > DOMs to XSLT Processors > owner-xsl-list@mulber > > rytech.com > > > > > > 02/03/00 10:25 AM > > Please respond to > > xsl-list > > > > > > > > > > All, > > Somewhere along the way, I got confused. Up until yesterday > afternoon, > I was of the thought that XSLT Processors such as XT, Xalan, SAXON, > and > Oracle's XML Parser for Java would accept standard DOM > (Document/Node) > objects as input. But, after having gone through all of them, I now > am > frustrated by the apparent fact that they are all file-centric. I'll > explain my situation. > > We're building a Java application that contains a piece that > retrieves > data from a mainframe via TCP/IP. The mainframe sends a > non-XML-formatted data string which we dynamically transform into XML > -- a DOM object. Yippee! The problem appears when we attempt to > apply > a stylesheet to the XML data. > > Assuming we parse the XSL stylesheet into a DOM object upon start-up, > we want to pass the just-generated data DOM and XSL DOM to the XSLT > processor and get back a stream of HTML. But none of the > above-mentioned XSLT processors provide publicly-accessible methods > that accept DOM arguments. > > SAXON doesn't use the DOM. Oracle's XML Parser for Java uses a > somewhat customized version of the DOM. Xalan and XT appear to use > standard DOMs, but we'll have to modify the source classes a little > because their pre- and/or post-processing logic isn't all publicly > accessible. And, for several reasons, that's not something with > which > we're entirely comfortable. > > Is there a reason why the API's don't readily provide for DOM (as > opposed to file) inputs? Am I showing my ignorance? Accessing the > XML > data and XST stylesheets from the filesystem on demand isn't a good > option for us, and I don't believe that any sort of production system > that needs responsive performance could put up with it. But I'd like > to get some thoughts on the subject. Thank you are any and all > input. > > > Mike..... > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > > > > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format