Saxon

Legacy ID: #4658603 Legacy Poster: Michael Kay (mhkay)

Saxon doesn't support the StAX push interface (event writer and stream writer). If you to send your query result to a push destination, please use SAX. It's possible that someone has written a bridge from SAX to StAX push interfaces, I don't know. As far as I know SAX is much more widely implemented than StAX, and it's not at all clear to me why the developers of StAX felt a need to add not just one more push API, but two.

Legacy ID: #4658974 Legacy Poster: David Lee (daldei)

Thanks very much ! I have found a SAX to StAX converter, and it should work. I'm not "stuck" on StAX, I'm experimenting ... If anyone has a suggestion I'd appreciate it. What I'm looking for is a common set of interfaces to use which can support the following Input: Read/Parse XML from InputStream Saxon libraries (XSLT, XQuery etc) other "yet unknown" XML libraries Some "event" stream type (see below) Output: Write/Serialize XML to OutputStream Saxon Libraries (as push ... ) hand coded java (simplier the better) Some "event" stream type (see below) By "event" I mean this. I want to implement a multi threaded XML "pipe" where the output of a XML producer can be fed to the input of an XML consumer in a 2nd thread. Ideally this is concurrently, and ideally such that the XML producer doesn't have to complete output before the XML consumer gets some. I've prototyped this with using DOM Documents, and it does work but is not ideal (for obvious reasons). I could implement it as a byte stream but that would require text serialization and text parsing for every stage. The StAX Event model seemed perfect for this, as I can generate a StAX Event stream and push it through a multi threaded blocking queue. However, given my recent experiences, it seems StAX is not at a state (yet) where inter-operation with divergent libraries and streams are as easy or efficient as I was hoping. Is there another common interface or class library which is more "standard" or implemented more widely that might have a better chance of working with a wide variety of sources and receivers ? I've tried most of the common ones, and they all seem to lack in some major areas (but different areas of course !). Eventually I got most of them to work, but with various non-ideal behaviour (IO Streams, Reader/Writer, DOM , StAX ) From what Mr Kay commented, I'm thinking maybe a SAX interface might be most interoperable. I could write my own "SAX Event" stream to handle my internal piping needs. Any other suggestions ? Thanks very much for any ideas. -David Lee dlee@calldei.com http://www.calldei.com

Legacy ID: #4659010 Legacy Poster: Michael Kay (mhkay)

What you describe is very much what SAX was designed to do, and SAX is widely used in that kind of pipeline architecture. Saxon does a lot of pipelining internally; it doesn't use SAX but instead has its own push interface net.sf.saxon.event.Receiver. That's not really designed for use outside the Saxon context, however. Michael Kay http://www.saxonica.com/

Legacy ID: #4659573 Legacy Poster: David Lee (daldei)

This is a very good suggestion. I agree SAX does seem the most well established and supported streaming XML API. However I am struggling with one issue, seemingly a huge roadblock. Certiantly I can push to SAX trivially using standard libs, and if I want to serialize the events in my own way (say to a multi-threaded queue of SAX events), no problem, just override ContentHandler and away I go. What I have NOT figured out, is how to get SAX events into various libraries and API's if they do not originate from an InputStream ... All the various Source and Reader type interfaces end up requiring an InputStream (or File, or System-ID or InputSource... all eventually lead to the same thing, an InputStream) which is presumed to be text serialized XML. If I had an alternate source of SAX "events", say a binary encoded (say Fast Infoset) or this nifty way-cool event queue, I could certianly feed my OWN code SAX events (again, just drive a ContentHandler), but I have yet to figure out how to get this input into JAXP or Saxon libraries. The JAXP stuff (Transformer.transform() ) underneath is very particular about the Reader actual class ... if its not one of its own it doesnt work. I havent found anything (yet !) in Saxon where I can feed it the "Item" needed for an XQuery source, or XSLT source constructed from my own SAX events. The closest thing I could find is StAX which Saxon supports as Input only, but not output. and SAX which works great for Output (but not input?). I really feel I must be missing something awfuly obvious ... but I'm at a loss, is there a single XML Streaming interface (or pair of interfaces) which is somewhat universally usable ? The only one I have been able to find ... is either DOM (ha , not exactly streaming ...) or text ... Any suggestions greatly welcome ! It just seems very odd ... I would think this is a common issue, and after 3 (4? 5?) generations of XML API's someone would have come up with the solution ... but maybe not, maybe thats why XProc is a difficult project instead of something trivial ... and why new API's keep being invented. Thanks for any ideas, I do greatly apprecate it. I'm almost resolved to reverting back text streams, which in my project would be somewhat ironic, as I'm actually attempting to emulate the Unix Shell philosophy ... but was hoping to avoid having to text serialize/deserialize every step. Thanks -David Lee dlee@calldei.com www.calldei.com

Legacy ID: #4659840 Legacy Poster: Michael Kay (mhkay)

>What I have NOT figured out, is how to get SAX events into various libraries and API's if they do not originate from an InputStream. If a component has been written so that it will only accept XML input from an InputStream, then there's not much you can do about it, you will have to serialize the XML so that the component can parse it again. There are quite a few components though that allow you to supply an XMLReader, or an XMLReader/InputStream combination, and in that case you can wrap any supplier of SAX events in a wrapper that makes it implement the XMLReader interface. Better still are components that directly implement the SAX ContentHandler interface. But I agree this isn't universal. Michael Kay