Re: Feeding DOMs to XSLT Processors

Yes.  I am more or less better, but still have that lingering muscle
pain and inability to go more than an hour without a nap.  B is deep in
the throes, so I suppose it will be tomorrow before things are better
for her.  Maybe this evening.

Beside the package light-bulb-going-on, I realized that the below would
actually be another very efficient way to do what you want with the SQL
stuff.  Instead of building a string then parsing it, you say,

  for-each row
     generate SAX-element name="row"
     for-each column
        generate SAX-element name="col"
        generate SAX-characters for content

No middle-men.  Much quicker.

 Steve

Kay Michael wrote:
> 
> Yes, absolutely the right approach. I've done similar things myself,
> generating a SAX event stream from something that didn't start life as XML,
> to allow XSLT to process it.
> 
> Mike Kay
> 
> >
> > Both Michael Kay and yourself recommended this approach (transform the
> > incoming data into SAX Events instead of DOM).
> > >
> > Would the following be feasible -- Pre-process the copybook into a SAX
> > InputSource instead of a DOM, at runtime, use the copybook SAX events
> > to parse the mainframe data string into a separate set of SAX events,
> > and then pass these events to the XSLT processor?
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

-- 
----------------------------------------------------------------------
Steve Tinney                                        Babylonian Section
                                 *   University of Pennsylvania Museum
stinney@xxxxxxxxxxxxx                          Phila, PA. 215-898-4047


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