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

Re: ANNOUNCEMENT: Proposed SAX Revisions

• From: Tyler Baker <tyler@i...>
• To: David Megginson <ak117@f...>
• Date: Sat, 21 Mar 1998 10:18:23 -0500

David Megginson wrote:

> The draft version of the Simple API for XML (SAX) came out just over
> two months ago, and it has proven far more successful than I expected
> -- hundreds of developers have downloaded the Java interface, four of
> the six Java-based XML parsers now contain native SAX drivers (I have
> written temporary drivers for the other two), and many people are
> designing applications built around SAX.
>
> After two months' experience with the draft interface, however, users
> have discovered four serious omissions in the original design:
>
> 1) there is no standard way to read an XML document from an input
>    stream;
>
> 2) there is no way to obtain contextual information (system id, line
>    number, etc.) for reporting application errors;
>
> 3) there is no way to obtain external identifiers for an attribute of
>    type NOTATIONS or ENTITIES when more than one notation or entity
>    name is provided; and
>
> 4) there is no way to distinguish between recoverable and
>    unrecoverable errors, as required by the XML REC.
>
> People have also rightly complained that the AttributeMap interface is
> too complicated.  I have put together a web page containing my
> suggestions for revisions to fix these problems and generally to clean
> up the SAX interface; you will find the proposed revisions at the
> following URL:
>
>   http://www.microstar.com/XML/SAX/proposed-changes.html

One thing which would be invaluable to may people from a performance perspective
is to change:

void startElement(String name, AttributeList attributes, Location loc) to:

boolean startElement(String name, AttributeList attributes, Location loc).

The boolean return value would indicate to the parser whether or not all sub
elements and sub content should be ignored which would let the parser arbitrarily
skip to the end element tag (if the element is not an empty element).  For
documents which only represent some sort of data storage mechanism where if one
element is unknown then all its child elements should be unknown, this would be
something very nice to have.

Also another change I would propose would be:

void endElement(String name, Location loc) to:

Also, it would be nice if Parser had some sort of pause/resume feature so you
could explicitly stop and start parsing at any point.  In this case you might
have every method return a boolean instead of void so that you could return true
to continue parsing or false to pause.

When dealing with multiple threads, this idea would be very nice as a control
mechanism since the InputStream that is passed as an argument might be being
filled up as you parse the document.  You don't want to stop parsing until you
know that the stream is closed.

Tyler


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

• References:
  • ANNOUNCEMENT: Proposed SAX Revisions
    • From: David Megginson <ak117@f...>

• Prev by Date: Re: ANNOUNCEMENT: Proposed SAX Revisions
• Next by Date: Re: ANNOUNCEMENT: Proposed SAX Revisions
• Previous by thread: Re: ANNOUNCEMENT: Proposed SAX Revisions
• Next by thread: Re: ANNOUNCEMENT: Proposed SAX Revisions
• Index(es):
  • Date
  • Thread