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

SAX: Parser Interface -- Summary of Change Requests

  • From: David Megginson <ak117@f...>
  • To: xml-dev Mailing List <xml-dev@i...>
  • Date: Sun, 1 Feb 1998 15:28:46 -0500

parser interface
As promised, I will now begin to summarise the requested changes to
SAX before we put out a stable 1.0 version: over the next few days, I
will send out one message summarising the requested changes to each
interface or class.  For more information on SAX, see

  http://www.microstar.com/XML/SAX/


There have been only two changes proposed to the Parser interface,
both of which would be backwards-compatible with existing
implementations:

1) Allow SAX to work with an input stream as well as a URI.

2) Simplify handler chaining by adding get* methods for existing
   handlers.


Here are the change requests in detail, with my initial response at
the end of each one:


1) Allow SAX to work with an input stream as well as a URI.

   - Paul Pazandak <pazandak@O...>
   - Peter Murray-Rust <peter@u...>
   - Don Park <donpark@q...>

   Currently, the Parser interface provides only the following method
   to initiate a parse:

     void parse (String publicId, String systemId)
       throws java.lang.Exception;

   Following this suggestion, there would be a new method

     void parse (String publicId, String systemId, InputStream input)
       throws java.lang.Exception;

   (It is still necessary to provide a system identifier for resolving
   relative URIs within the stream).  Note that the stream would be a
   byte stream, not a character stream -- characters might require
   more than one octet, depending on the encoding in use.  

   I can see the convenience of this method, and I plan to add
   something like this to AElfred when I have a chance.  For SAX,
   however -- which is meant to end up as a language- and
   system-independent API -- I am reluctant to hardcode assumptions
   about storage (and I don't know enough about IDL to know if there
   is a general representation for streams).  Paul Pazandak has also
   suggested allowing strings and buffers -- in this case, they would
   already be decoded into characters.

   Personally, I'm undecided, and would be interested in hearing the
   theoretical arguments for and against this suggestion.


2) Simplify handler chaining by adding get* methods for existing
   handlers.

   - Don Park <donpark@q...>

   Currently the Parser interface provides only setters for the
   various handlers:

     public void setEntityHandler (EntityHandler handler);
     public void setDocumentHandler (DocumentHandler handler);
     public void setErrorHandler (ErrorHandler handler);

   Following this suggestions, there would also be accessors:

     public EntityHandler getEntityHandler ();
     public DocumentHandler getDocumentHandler ();
     public ErrorHandler getErrorHandler ();

   An application could then retrieve the existing handler and
   implement a new one which invokes the old one under certain
   circumstances.

   This seems like a generally good idea (as will as a simple and
   backwards-compatible change), and I am willing to implement it.
   The only complication is that we'll have to define the default
   state -- is the parser always required to return a default handler
   if the user has not explicitly set one, or should it return null?


I look forward to your comments and suggestions.


All the best,


David

-- 
David Megginson                 ak117@f...
Microstar Software Ltd.         dmeggins@m...
      http://home.sprynet.com/sprynet/dmeggins/

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...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.