New SAX Version

[Charles Reitzel]

1) Agree w/ David Megginson's priorities:

>... the following for SAX 1.0 are probably higher priorities:
>
>1. A proper specification for SAX (JavaDoc just doesn't cut it).
>2. A test suite for SAX conformance.
>3. Canonical SAX interfaces for Perl (on top of XML:Parser) and C++.

I volunteer to work on a C++ implementation.

2) Some additional SAX features (e.g. driver/filter manager, Element/Object
factory) are "orthogonal" to the core interfaces.  Why not create separate
packages for these?  A default rule like "Additional SAX packages will
depend only on the core package" will keep things manageable.  

3) Isn't it too soon to freeze any XML related specs because of the
"installed base"?  I think the time tested approach is to maintain existing
interfaces for backward compatibility for release or three after they are
officially deprecated.  Sometimes this means that new names must be used
where you would prefer not to but, hey, that's life in the big city.  An
update once a year won't thrash anybody's code.  So, it's better to get in
fixes for those few wee problems with the core API's than wait for the
installed base to grow by an order of magnitude and it really will have to
freeze.

4) Is it a good idea to hard-wire each SAX version to an XML version?  I
think ODBC would be a pretty good model to follow here.  Each version of the
driver manager (ODBC itself) defines how it will interact with drivers
written for earlier versions of ODBC.  ODBC v2 can handle v2 and v1, etc.
ODBC pretty much froze a v2 because a) it was pretty complete and b) the
installed base became huge.


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