This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
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@sas.upenn.edu Phila, PA. 215-898-4047
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list