Lists Home |
Date Index |
- From: David Megginson <firstname.lastname@example.org>
- To: email@example.com
- Date: Fri, 17 Apr 1998 07:23:13 -0400
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
- it must be able to report basic parsing events (start/end of
- 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 firstname.lastname@example.org
Microstar Software Ltd. email@example.com
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)