Re: [boost] Proposal: XML APIs in boost

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2005-11-01 02:36:59

* Stefan Seefeld <seefeld_at_[hidden]> [2005-10-31 22:47]:
> Some years ago I proposed a XML-related APIs for inclusion
> into boost (http://lists.boost.org/Archives/boost/2003/06/48955.php).
> Everybody agreed that such APIs would be very useful as part of boost.
> Unfortunately, though, after some weeks of discussing a number of details,
> I got distracted, and so I never managed to submit an enhancement.
> 
> I'v now started to look into this topic again, and wrote down a start
> of a DOM-like API as I believe would be suitable for boost.
> 
> Here are some highlights:
> 
> * User access dom nodes as <>_ptr objects. All memory management is
>    hidden, and only requires the document itself to be managed.
> 
> * The API is modular to allow incremental addition of new modules with
>    minimal impact on existing ones. This implies that implementations
>    may only support a subset of the API. (For example, no validation.)
> 
> * All classes are parametrized around the (unicode) string type, so
>    the code can be bound to arbitrary unicode libraries, or even std::string,
>    if all potential input will be ASCII only.
> 
> * The Implementation uses existing libraries (libxml2, to be specific),
>    since writing a XML DOM library requires substantial efford.
> 
> A first sketch at a XML API is submitted to the boost file vault under
> the 'Programming Interfaces' category. It contains demo code, as well
> as some auto-generated documentation.
> 
> I'm aware that this requires some more work before I can attempt
> a formal submission. This is simply to see whether there is still
> any interest into such an API, and to get some discussion on the
> design.

    I'm going to respond off-the-cuff, so excuse me if what I
    mention is covered in your sketch.

    Simply, the Java APIs have moved away from W3C DOM. In that
    langauge, developers have moved to JDOM, DOM4J, or XOM, for node
    surgery.
    
    The W3C DOM predates namespaces, and namespaces feel kludgy. It
    permits the construction of documents that are unlikely in the
    wild. Most documents conform to XML Namespaces.

    Of those alterate object models noted above, only DOM4J
    separates interface from implementation as rigidly as W3C DOM,
    using the factory pattern to create all nodes.

    More recent object models in Java like XMLBeans move away from
    modeling XML as a tree of nodes connected by links, and instead
    models XML as a target node, with a set of axis that are
    traversed by iterators, rather than node references.

    This model is the most C++ like.

    There are also document object models coming out of XPath and
    XSLT that are not as well known but are all axis based.  Saxon's
    NodeInfo model, Jaxen's Navigator model, and Groovy's GPath model.

    All of these models are immutable. They support transformations
    and queries. For many applications this is all that is necessary.

    XQuery, XSLT, and XPath all generate new documents from
    immutable documents. The need for document surgery for many in
    memory applications is not as common as one might think.

    Transformation is often easier to express. 

    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'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.

    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.

    Cheers.

--
Alan Gutierrez - alan_at_[hidden] - http://engrm.com/blogometer/