OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <ak117@freenet.carleton.ca>
  • To: Tyler Baker <tyler@infinet.com>
  • Date: Mon, 2 Feb 1998 15:50:00 -0500

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@freenet.carleton.ca
Microstar Software Ltd.         dmeggins@microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS