Eric SCHAEFFER wrote: > Can you be more explicit ? Look at java.io.PipedReader/Writer for the streaming.
A little more on the point I made about being able to associate errors with the actual DOM node that caused the error. This can be done but requires a little more work on your part. First of all, you need a serializer that can walk the DOM tree, writing to the PipedWriter *and* knows about the parser instance used to parse the stream and register itself as an error handler. Does this make sense? In addition, the parser is setup, by default, to buffer large portions of the document stream for performance reasons. If you want to have parsing errors occur when the associated nodes are being serialized, then you have to use a parser instance that doesn't buffer its input. We don't have an example of doing this but I can point you in the right direction. Check out the org.apache.xerces.readers.StreamingCharReader class as well as the org.apache.xerces.readers.DefaultReaderFactory class. The DefaultReaderFactory is used by the parser to recognize the XML or Text decl lines and construct an appropriate reader to handle the document. By default, the reader factory always returns buffered readers. You can create a subclass of this factory to return StreamingCharReader objects instead. Then it's just a simple matter of making a parser subclass that uses your new reader factory instead of the default one. I hope this is enough information to get you started. If you write the code for the streaming parser instance, please contribute the code so we can add it to either a) the primary Xerces package or b) as a contributed extension. Perhaps the whole issue of contributions needs to be thought about and decided upon. Anyone with thoughts on this? -- Andy Clark * IBM, JTC - Silicon Valley * [EMAIL PROTECTED]
