ModSAX (SAX 1.1) Proposal

[Tyler Baker]

Clark Evans wrote:

> I think it would be better to start with Requirements,
> then some Analysis instead of jumping straight to Design.
>
> So that I'm not stopping the show, here are
> nice things that I'd like to see:
>
> 1. A mechanism to include multiple observers
>    in parallel.  If this dosn't already work.

I think in Michael Kay's SAXON package he has some multicast DocumentHandler object that does
just this.  All it does is delegate processing to a list of DocumentHandlers.

> 2. A way to register said observers for particular
>    events, e.g., an "event mask".

Since SAX is based upon a callback API rather than some abstract event type, I am not so sure
this is at all necessary unless things move the way Bill la Forge suggested with using event
objects.  I am particularly not in favor of the event objects approach because it is an extra
layer of indirection in handling the parsed data that I don't think adds anything positive to
SAX.

> 3. Complete capababilities management.
>
> 3.1. I'd rather not ask the SAX driver if it
>      supports events X,Y,Z,P,D,Q.  I'd like
>      a more "package" oriented mechanism.

What do you mean by package oriented.  If you talking about having special possibly inherited
DocumentHandlers for each type of add-on, then I am all for it.  This way you could have a
NamespaceDocumentHanlder which would present namespace handled content to the application in
an appropriate form.  Changing the ParserFactory class to add additional static methods for
location a NamespaceParser or an ExpandEntityParser or whatever would be totally backwards
compatible.

Of course the obvious problem with this is the interface explosion problem which would be a
direct contradication to SAX's goal of being simple.

> 3.2  Versioning of these packages and events.
>
> 4. Event stack support.

I have done something like this before and it is particularly useful, especially for
error-reporting.  Of course the big problem with this is that you need to create new event
objects to put on this stack.  This would slow down many of the fastest XML parsers five fold.

> Some of these are a bit far-out, but it's hard
> to know what the "specific goals" of SAX 1.1 are.

Probably roughly the same, or else it would need to change its name, "Simple API for XML" (-:

Tyler


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/ and on CD-ROM/ISBN 981-02-3594-1
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)