YAXPAPI (Yet Another XML Parser API)- an XDEV proposal

[Simeon Simeonov]

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.

Regards,

Simeon Simeonov
Allaire


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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)