Graham Bennett wrote:
Hi Doug,
On Tue, Nov 08, 2005 at 09:28:09PM -0500, Douglas Gregor wrote:
Readers are important for some things, DOM is important for other things, but there's no reason to tie the two together in one library or predicate one on the other.
Well, there is at least one reason - if the DOM is built on top of a reader interface then the DOM library doesn't have to know how to parse XML, and is not tied to any particular parser. Even if you don't agree with using a reader interface for this separation layer, I'd hope you would agree that some separation is at least necessary.
I wish people would stop being so parser-focussed. I reiterate: the API I suggest is about manipulating a DOM tree. The fact that you *might* want to construct it from an XML file by means of a parser is almost coincidental. Yes indeed, an implementation of such an XML parser will most likely use either a SAX or an XmlReader layer beneath, and in fact, libxml2 does exactly that and it would be quite natural to expose those APIs to C++ in a similar way I propose the DOM wrapper.
We can have a XML DOM library that allows reading, traversing, modifying, and writing XML documents, then later turn the reading part into a full-fledged streaming interface for those applications.
Can you elaborate on how you would enable a DOM structure to present a streaming interface?
Not the DOM structure, but the parser ! It's exactly what you are saying above: Each sensible XML parser will use an API underneath that can be used to build a public SAX or XmlReader (or both) on top of. But instead of requiring the parser to be built on such a C++ API I use a C implenentation that already contains multiple APIs, and I wrap them *separately* into C++ APIs. For a user of the C++ DOM API it is totally irrelevant whether the implementation is based on the C++ SAX API or an internal C SAX API, as long as it adhers to the specification.
Are you talking about lazy tree building or something else? In any case, I would think it's inherantly difficult to retrofit a streaming interface. Much better to build the streaming interface from the start, and build the DOM on top of it. This can only be good for both sides - the reader gets to just be a reader, and the DOM gets to just be a DOM.
You haven't talked about the DOM yet, only about a parser. You still need to provide all the other missing bits, such as an XPath lookup mechanism, XInclude processing, http support for URI lookup, etc., etc. I can't stress it enough: the parser is really just a tiny bit of it all. Regards, Stefan