[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX: Parser Interface -- Summary of Change Requests

  • From: David Megginson <ak117@f...>
  • To: Tyler Baker <tyler@i...>
  • Date: Mon, 2 Feb 1998 15:50:00 -0500

summary of change
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 Megginson                 ak117@f...
Microstar Software Ltd.         dmeggins@m...

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.