YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
simeons at allaire.com
Sun Dec 14 21:55:22 GMT 1997
I come to this discussion late (4:30pm EST on Sunday :) so my set of
assorted notes is addressed at no one in particular.
I like the acronym SAX. It's short and sweet.
In principle I agree with the idea that an API simpler than what DOM exposes
will be useful. This is especially true in the short run--until fully DOM
compliant implementations with a variety of language bindings become readily
available. I absolutely agree with the need for both event-driven and a
tree-based interfaces. My product, the Cold Fusion Application Server, needs
both. And it really only needs to know about text, elements, and attributes.
All else is currently of no interest to the tens-of-thousands of web
application developers that use CFAS.
A note of caution. I hope that in your mind SAX is not the same as SAX-J.
Some of the API proposals I have seen have a very strong Java flavor. For
example, I see the need for an API that does not require runtime type
information. The equivalent of instanceof in C++ is the dynamic_cast<T>()
operator. It requires the enabling of RTTI which imposes an immediate and
quite noticeable size and performance penalty. IMHO, runtime type
information is necessary only when the object model of a system is
undergoing continuous change. I don't see this being the case with SAX.
I cannot invest the time in writing an XML parser in C++ right now, but I'd
be more than happy to contribute to this discussion to make sure that SAX is
a C++-friendly API.
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/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev