SAX C/C++ Implementations?

Steinar Bang sb at
Tue Sep 28 19:05:22 BST 1999

>>>>> <mlepage at>:

>> Since I had to make this work on some parsers without proper namespace
>> support I prefixed the classes with "sax_".

> You mean compilers?

Yes, sorry!  The compilers in question are Sunpro 4.1 and egcs/gcc
(currently egcs 1.1.2-pre2).

> Sounds reasonable, but I'd like to see any C++ implementations
> account for the possibility of using C++ namespaces. That's what
> they're for!

Sure, agreed!

[snip! const string& instead of const string*]
> How can the application tell the difference between a non-existent
> attribute, and an empty attribute?

Um... does it need to?  Mine won't... I think.

> I can think of cases where, if not available, an application might
> find an attribute value using some other mechanism (e.g. ask the
> user). How can the XML document set the attribute to an empty
> string, without invoking that other behaviour?

I see the need.  It will pop up if one adds DTD and/or schema
awareness.  I don't like using pointers to std::string.
How about something like this?

class sax_AttributeList {
    enum AttrType {

    virtual ~sax_AttributeList();

    virtual int getLength() const = 0;
    virtual bool getName(string& name, int i) const = 0;
    virtual bool getType(AttrType, int i) const = 0;
    virtual bool getValue(string& val, int i) const = 0;
    virtual bool getType(const string& name, AttrType& typ) const = 0;
    virtual bool getValue(const string& name, string& val) const = 0;

Ah, yes!  Here's another change I did: I made the type an enum instead 
of a string.  Since it's a limited set, why take the overhead of
storing strings? (expat doesn't have this information anyway, so it
doesn't really matter if as long as we use it).

> That all sounds reasonable, especially for a private (protected?) 

Not neccessarily!  I'll ask.

> implementation. My personal feeling is that as long as we are close,
> if a standardized version becomes available, it shouldn't be too
> hard to get in line with the standard. More so than if we just used
> whatever parser interface was available, and not a SAX-like
> interface.

My thoughts exactly!  Hopefully all of our platforms are moving
towards Standard C++.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list