Re: [boost] Proposal: XML APIs in boost

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-11-01 09:13:18

Alan,

thank you for your interesting points. The API I suggest is not
modeled after the the W3C DOM IDL, neither its java implementation.

Many people have expressed discomfort both with the W3C DOM API
as well as the idea of simply transcribing the java API to C++.

Therefor, the API I suggest here is (so I hope) as C++-like as
it can be, while still giving full flexibility to operate on
(i.e. inspect as well as modify) XML documents.

 From the little I could gather about the alternatives you mention,
it sounds like they would make very nice access layers on top of
the base API (axis-oriented iterators, say).

>     I'd suggest, in any language wide implementation of XML, to
>     attempt to separate transformation and query, from update. They
>     are two very different applications.

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) ?

>     I'd suggest starting with supporting XML documents that conform
>     to the XPath and Query data model, and working backwards as the
>     need arises. It makes for a much more consice library, and
>     removes a lot of methods for rarely needed, often pathalogical,
>     mutations.

There are clearly very different use cases to be considered. We should
collect them and try to make sure that all of them can be expressed
in a concise way. I'm not sure all of them operate on the same API layer.

The code I posted supports xpath queries. While the result of an xpath
query can have different types, right now only node-sets are supported
(May be boost::variant would be good to describe all of the possible types).
I'm not quite sure I understand what you mean by 'XPath data model'.

>     Implementing an object model would be much easier, if you
>     ipmlement the 95% that is most frequently used. And if you
>     sepearate the compexity of document mutation from the realative
>     simplicity of iteration and transformation.

Could you show an example of both, what you consider (overly) complex
as well as simple ? While the API in my code is certainly not complete
(namespaces are missing, notably), I find it quite simple and intuitive.
I don't think it needs to become more much complex to be complete.

In particular, I'm hoping that we can make the API modular, so document
access and document validation are kept separate (for example). May be that
is what you mean, I'm not sure.

Regards,
                Stefan