[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX/C++ vs. SAX2

• From: Michael Fuller <msf@m...>
• To: David Megginson <david@m...>
• Date: Mon, 6 Dec 1999 14:47:19 +1100

On Fri, Dec 03, 1999 at 01:21:38PM -0500, David Megginson wrote:
[Re: whether to work on SAX2 or on SAX/C++]
> I can think of a few reasons that the world might desperately be
> waiting for SAX2:
> 
> 1. To get some kind of standard Namespace support (or at least a way
>    to tell whether a parser has Namespace support built in).
> 
> 2. To query parser features in general.
> 
> 3. To get at the stuff that SAX 1.0 doesn't report, like comments,
>    CDATA boundaries, and DTD declarations.
> 
> I'm very interested in hearing other opinions.  Having a standard
> streaming interface stimulated a lot of development of reusable Java
> XML processing components, and I'd like to see the same thing happen
> in C++, but I need to hear what other people think the priorities
> should be.

#1 clearly is important; if only to ensure that SAX remains a
desirable and viable interface. If application developers or
parser writers are start to walk away from SAX due to a lack 
of namespace support, then SAX will rapidly die.

#3 is vital for many XML *processing* applications.

If you want to provide a SAX interface to an XML database server
that must be able to round-trip documents, SAX 1.0 isn't enough.
If you're writing an editor, or an XSLT engine, or a compound
document manager, or a transport protocol like WBXML, you want
or need to know about things that are in the SAX2 LexicalHandler
(e.g. CDATA sections, comments), NamespaceHandler, and DeclHandler.

For other applications, #3 isn't relevant. But that's the value of #2:
parser writers can implement the features and support the properties
they wish to, and application writers can selectively invoke that
functionality.

As it happens, I'm in the process of implementing a SAX interface for
a couple of SIM-related projects. We need, I think, the functionality
that SAX2 provides. Given that our code base is in C++, I guess my
vote is for both: a stable SAX2 and a standard C++ definition.

But having taken a look at SAX2, not much seems to be wrong with it.
Whereas there's already close to a dozen SAX/C++ variants, and climbing.
*That* trend needs to be stepped on, and quickly, before it gets out of hand.

Michael
____________________________________________
http://www.mds.rmit.edu.au/~msf/
Multimedia Databases Group, RMIT, Australia.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • SAX/C++ vs. SAX2
    • From: David Megginson <david@m...>

• Prev by Date: Re: expat meant to be restartable?
• Next by Date: Re: SAX/C++: Changes for C++
• Previous by thread: Re: SAX/C++ vs. SAX2
• Next by thread: Re: SAX/C++ vs. SAX2
• Index(es):
  • Date
  • Thread