xml-dev - Re: SAX C/C++ Implementations?

[<mlepage@antimeta.com>]

On Tue, Sep 28, 1999 at 07:04:55PM +0200, Steinar Bang wrote:
> >>>>> <mlepage@antimeta.com>:
> 
> >> 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).

Sunpro 4.1 is hopelessly out of date. I started using it almost 3 years ago, that's an eternity. I believe Sun has new compilers available.

GCC 2.95.1 installs easily in /usr/local (configure, make, make install) and seems to work great. It's still not entirely standard compliant, but in many ways more so than VC++6.


> [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 don't think yours will, that's why I didn't take that route. In my opinion, if you request the value of a non-existent attribute, an exception should be thrown. The reason is simple: the function cannot do what it promises to do. Perhaps also a function should be added to tell if a particular attribute is present. Again, these are interface changes over and above a "straight" port of SAX from Java to C++.


> > 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 {
> public:
>     enum AttrType {
> 	undefined,
> 	CDATA,
> 	ID,
> 	IDREF,
> 	IDREFS,
> 	NMTOKEN,
> 	NMTOKENS,
> 	ENTITY,
> 	ENTITIES,
> 	NOTATION
>     };
> 
>     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).

I agree that an enum, in this case, is preferable to the strings. Again, that's a bigger interface change than a "straight" port. I also don't mind the method of returning a string where it is copied into a reference parameter. Other than using the reference, that's how Lakos recommends returning something, if I recall correctly.


> [snip!]
> > That all sounds reasonable, especially for a private (protected?) 
> 
> Not neccessarily!  I'll ask.

Ideally, we'd at least get our interfaces, and Jez', synchronized. I predict more difficulty with IBM's. Finally, I've been doing as "straight" a port as possible; ideally, for a more "C++-ized" port, we'd get more blessing from Megginson for the interface changes we make. That's as close to a standard as we probably can get.

Also, my Expat driver is extremely simple. It lets me parse XML, but mostly I focussed on the document handler methods. I'm not sure I know enough about the rest to properly support, for example, the element/attribute types. I would appreciate advice on this matter, or your code.  :-)  My expertise lies more in the C++, patterns, OOA/OOD, solid code, area.

-- 
Marc Lepage  (aka SEGV)
http://www.antimeta.com/
RTS game programming info, Minion open source game, etc.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)