[boost] Re: API Review request: XML API for C++, second round

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-06-27 06:53:34

Hamish Mackenzie <hamish_at_[hidden]> writes:

> On Fri, 2003-06-27 at 09:09, Anthony Williams wrote:
> > What's wrong with just having boost::shared_ptr<Document> and
> > boost::shared_ptr<Node>, boost::shared_ptr<Element> ?
> > 
> > You could have each node store a boost::weak_ptr<Element> pointing to its
> > parent, which is converted to a boost::shared_ptr<Element> when you ask for
> > it. That way, a child doesn't keep its parent alive (though parents should
> > keep their children alive), but you can still traverse up the tree if you
> > like.
> > 
> > You could do the same for documents --- the document holds a shared_ptr to
> > the root element, and so keeps the whole tree alive. Each element holds a
> > weak_ptr to the document, so you can retrieve the document from it, but it
> > doesn't keep it alive. Consequently, if you erase an element from the
> > document, but you still have a pointer to it, then the element itself is
> > OK, but it will then die when your pointer goes out of scope. Also, if the
> > document goes out of scope, then your element is still OK, but is no
> > longer associated with a document.
> 
> This sounds like a description of an implementation rather than the
> interface.  This implementation would not solve the problem "what is a
> node when it is not part of document?".

It was meant to be a description of semantics, in terms of a sample
implementation.

A node that is not part of a document is a free-standing subtree that needs
adding to a document. If it is an element, then you can treat it as if it is
the root node of a document. If it is anything else, then you are more limited
in what you can do, but then what does it mean to perform an XPath query on a
PI?

If the underlying API requires that the document is kept alive to keep the
nodes alive, then the wrapper class must handle this, whilst simulating the
above semantic description.

> Your implementation would be much easier to wrap than libxml2.  You
> could implement the same interface simply with...
> 
> typedef Document document;
> typedef Node * node_ptr;
> typedef Node & node_ref;
> 
> The problem when wrapping libxml2 is that the node is stored by libxml2
> in its own xmlNode structure.  You can't add methods to it like you
> could if you wrote your own Node.
> 
> You could copy the libxml2 tree into your own structure but then you are
> on your own when it comes to higher level things like xpath and xslt.

I imagined that you would write forwarding functions for the underlying API,
so when you are given an Xpath query, you pass it on to the underlying API and
then wrap the result.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.