SAX: Character Stream vs. Byte Stream proposal...

David Megginson ak117 at
Fri Apr 17 13:24:35 BST 1998

Tyler Baker writes:

 > Why not simply have a standard factory that takes any type of
 > InputStream (UTF-16, UTF-8, etc) similiar to how the parse method
 > works and it returns a type (say CharacterStream) which can then be
 > passed to either the parser or the application.  In this case the
 > implementations for doing all of this low level character reading
 > from bytes could be standardized for each platform.

The problem is that SAX is an API, not an architecture -- that is, it
attempts to impose the fewest possible constraints on implementations.
There are several good reasons for this approach:

1. SAX is one of (possibly) many APIs that an XML parser will
   implement, and other APIs may make conflicting demands.

2. XML parsers need to compete on speed, memory usage, etc., and to do
   so, they need to be free to take different approaches.

Right now, there are already four major constraints that SAX imposes
on an XML parser writer (other than the constraints already imposed by
XML 1.0):

- it must be able to report basic parsing events (start/end of
  elements, etc.)
- it must be able to take input from a character stream
- it must be able to report errors to a handler without automatically
  throwing an exception
- it must be able to call a resolver before opening external entities

The first two constraints are quite reasonable; the third and fourth
may already be somewhat objectionable, and the fourth, in particular,
requires modifications to existing parsers.

Note that it is _not_ a requirement that the parser support
localisation of error messages, that it be able to report attribute
types (other than "CDATA"), that it actually use anything in
DTDHandler, or that it actually provide a Locator object.

All the best, and thanks for the comments,


David Megginson                 ak117 at
Microstar Software Ltd.         dmeggins at

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

More information about the Xml-dev mailing list