Re: Feeding DOMs to XSLT Processors

[Paul Levin <plevin at bii dot com>]

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



Michael Harry Scepaniak wrote:

> 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


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list