On Nov 8, 2005, at 7:44 PM, Graham Bennett wrote:
IMO a streaming interface is much more important than DOM as a starting point - one can easily and efficiently build a DOM from a stream, but starting with an in-memory representation of a document usually precludes streaming. There are a number of XML applications where it is not desirable or possible to hold the entire document in memory at once. A reader interface has advantages over SAX in that it is much easier to program with. It's very easy to do things like implement decorators around readers, and to write generic code that just understands how to use a reader and doesn't care how the XML is actually stored.
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. 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.
That's not to say I don't think a Boost DOM implementation is a good idea. One thing I would like to see from such an implementation is for it to be policy based, since there are many different use cases for a DOM library. For example some scenarios might only need a read-only tree, which means optimisations can be made in how the nodes are stored. Others might call for efficient access to child elements of a node (e.g. by index) for query, such as when XPath is used. If this kind of thing could be extracted into policies I think it would differentiate such a library from the others that exist already.
[Standard anti-policy rant] Policies should be used very, very carefully. They introduce a huge amount of mental overhead, are very hard to combine sensibly, and create very fragile implementations.
An XPath implementation should be completely separated from the XML representation, since it's effectively just an algorithm that can be applied to anything that has the correct data model and iterator interface.
This is probably the case. However, one can think of places where a tighter integration might give a more natural interface, e.g., xml::element_ptr books = ...; xml::node_set cheap_books = books[attr("price") < 30]; But, like the reader interface, a library that supports something DOM- like can be augmented with XPath support. Doug