Re: [boost] Proposal: XML APIs in boost

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-11-02 08:58:03

Alan Gutierrez wrote:

>>I'm not sure I understand what you mean by transformation. How
>>is it different from update ? Or is the former simply a (coarse-grained)
>>special case of the latter, using a particular language to express
>>the mapping (such as xslt) ?
> 
> 
>     Transformation engines are XQuery, XSLT, STX, and Groovy GPath.
> 
>     They do not update the document provided. The produce a new
>     document. That is what I mean by transformation. The input XML
>     document is not changed, it is read, and a new document is emitted.

Fine. An what API are you looking for to do such transformations ? What's
the granularity that makes the most sense ?

document_ptr document = parse_file(input);
stylesheet_ptr transformer = load_stylesheet(stylesheet);
document_ptr new_document = transformer->transform(document);

ought to be enough, no ?

>     The document object model does not need to be mutable. Thus you
>     can perform all sorts of optimizations for navigation.

Could you provide an example ? I'm not sure I see what you have in mind.

>     The ability to add or remove a node makes a document object
>     model far more complex.

Really ? Look at my design, there aren't all that many methods to begin with,
and only a fraction are about modifying documents / nodes. I believe that
non-modifiable documents aren't that frequent that they require an entirely
different object model.

>     Many people prefer this mode of operation over adding and
>     removing nodes.

As I said, the idea of an API to navigate based on axes (for example) sounds
very interesting and elegant, but I believe that could easily be layered on
top of the API I'm presently proposing.

>     Node insert/remove appears to be a common operation, because of
>     web programming, where chaning the dom in the browser changes
>     the display of the page.

I don't quite agree that this is the number one use case. I haven't
actually looked into boost::serialization, but I'd expect a DOM API
to be useful there. I'v written libraries for data management that
used some kind of DOM API, too. Or configuration data, or...

>     When you are not programminng for the pretty side-effects, node
>     surgery becomes a real pain. Reading the document in, shuffling
>     nodes, writing it back out is cumbersome. A lot of code is spent
>     on the add and remove that is repetitious.

Ok, so let's make it concise then. But someone has to create the
document that you want to read in and transform. And may be that
someone would prefer boost::xml if it existed. :-)

Regards,
                Stefan