Re: [boost] Proposal: XML APIs in boost

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-11-08 21:28:09

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