SAX: Parser Interface -- Summary of Change Requests

[David Megginson]

Tyler Baker writes:

 [on reading XML from a stream rather than a URI]

 > Well, what if the XML data is streamed from a database where a URL
 > does not matter so much.  If you look at what Oracle, Sybase, and
 > Microsoft among others are planning on doing with XML, then
 > supporting this with SAX in the most ubiquitous way will be very
 > much necessary.  I think that if you want to make SAX have any
 > CORBA support or other language support down the line, it would be
 > best to negate any polymorphism in the API cause in CORBA for
 > example, you cannot redefine operations in IDL (methods in Java).

This is a good point, but there are complications.  Do these vendors
plan to use character streams or byte streams?

 > Another idea (as far as implementation goes) is to have the parser
 > simply be an extension of java.io.FilterInputStream which takes an
 > one or more Handler interfaces as arguments (to delegate to), so
 > that you can handle very large streams of data.

This sounds like an interesting idea for a parser implementation, but
since SAX is meant to work with many parsers in many languages, it is
probably too constraining as a general common interface.

 [on get* methods for handlers]

 > Not sure exactly what the use of these get methods is for cause all
 > the handlers are useful is delegation anyways.  The only reason the
 > get methods would be useful is for casting the returned object to
 > some other form.  Why anyone would need to do this is beyond me as
 > recasting this object back to something would be sloppy
 > implementation in the first place.

Delegation itself might be enough justification, though -- we'll have
to wait and see what others suggest.

 > The default handler could just be something which spits stuff out
 > to stdout or some other OutputStream in a manner similiar to how
 > Aelfred's EventDemo does.

It would probably be best for the default handler to produce no output
at all, so that other handlers delegating to it would not end up
creating bloated log files.


All the best, and thanks for the feedback,


David

-- 
David Megginson                 ak117 at freenet.carleton.ca
Microstar Software Ltd.         dmeggins at microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)