Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX C/C++ Implementations?
>>>>> <mlepage@a...>:
>> 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 {
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).
[snip!]
> 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@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...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
