Subject: Re: Feeding DOMs to XSLT Processors From: Steve Tinney <stinney@xxxxxxxxxxxxx> Date: Mon, 07 Feb 2000 12:30:07 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Feeding DOMs to XSLT Processors, Kay Michael | Thread | Re: Feeding DOMs to XSLT Processors, Michael Harry Scepan |
RE: HTML Forms and XSL, Ben Robb | Date | Preserve White-Spacing, tmmet tvp |
Month |