The SAX interface of the xml4c2 parser

[Richard Anderson]

>         http://www.vivid-creations.com/free/sax.h

The page for the C++ variant is : http://www.vivid-creations.com/xtl.htm
The COM variant for Delphi, VB and most other langauges is :
http://www.vivid-creations.com/sax/index/htm

It is currently being revamped with new features (mainly for the DOM) so any
requests for changes should be sent to : requests at vivid-creations.com

The SAX interface has been expanded with a cdata() method to enables DOMs to
be built with CDATA sections, and if there is any real benefit SAX2 will be
supported.

----- Original Message -----
From: Steinar Bang <sb at metis.no>
To: <xml-dev at ic.ac.uk>
Sent: Friday, October 22, 1999 11:48 AM
Subject: The SAX interface of the xml4c2 parser


> I've taken a look at the SAX interface of the IBM xml4c2 parser
>         http://www.alphaworks.ibm.com/tech/xml4c
>
> In short, I don't like it.
>
> I don't like returning "const XMLCh*" instead of "const wstring&" or
> "const string&" (even though an approach like this would be more
> efficient for an expat wrapper).  I don't need the index out of range
> warning capability, because I iterate through the AttributeList
> entries anyway.
>
> I don't like giving an AttributeList& argument to
> DocumentHandler::startElement(), instead of an AttributeList*, because
> this rules out the possibility of passing a null-pointer on for the
> cases that don't have an attribute list.
>
> Hm... so far there is AFAIK 4 incompatible C++ SAX implementations
> around.  The IBM one, and:
>         http://www.jezuk.demon.co.uk/SAX/
>         http://www.cgocable.net/~mlepage/minion/doc/
>         http://www.vivid-creations.com/free/sax.h
>
> I also have an expat-wrapper-based C++ SAX implementation, similar to
> Jez Higgins' one (I use a "sax_" prefix instead of namespaces, since
> it has to run on compilers without namespace support).  No time to
> create a web page for it yet.
>
> My reasons for going SAX, was:
>  1. it seemed silly to invent my own abstraction when lots of work had
>     already gone into the SAX design
>  2. make it possible to drop-in replace the parser
>
> But #2 can only be achieved if the different SAX implementations have
> the same API, and this is not currently the case.
>
> I'll go whatever way the majority goes, unless it leads towards the
> IBM implementation.
>
> 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 unsubscribe, mailto:majordomo at ic.ac.uk the following message;
> unsubscribe 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)
>


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 unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)