Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2003-06-02 08:42:49

Stefan Seefeld wrote:

>What I originally suggested was not a parser, but a set of APIs to
>manipulate XML. The parser part (i.e. the piece of code that generates
>a parse tree from an XML file) is the simples part of it all. What
>is much more tricky is to get the right internal structure to make
>operation on the tree efficient and convenient.

>That said, I would *not* recommend to rewrite any such thing. It is
>a *lot* of work, and as such quite unrelated to boost's goals.

Would also mapping an implementations structure to a C++ internal structure
also require quite a bit of work?

OPTION 1: C++ specific internal mappings.

boost::xml::dom::document doc( "demo.xml" );

class document
      boost::xml::dom::element root;
      document( const char * fn )
         impl::XMLDOMDocument doc( fn );
         BuildXMLDOM( doc.documentElement, root );
      void BuildXMLDOM( impl::XMLDOMElement, boost::xml::dom::element & );

Where BuildXMLDOM recursivley builds the internal XML tree structure.

NOTE: This is necessary if you want to use an internal C++ representation to
efficiently model the structure for C++ bindings, e.g. using trinary search
trees or other associative container for attribute storage.

This would make the loading of an XML document more computationally and
memory intensive because you have to load it twice (one by the parser and
one by the C++ bindings). There are problems in this regard when loading
large documents (effectively having double the memory capacity). Also, what
about SAX facilities?

OPTION 2: If you are intending to wrap an implementation like libxml2 into a
C++ interface, you would sacrifice how the data is represented internally
and you would get a slight performance penalty from the wrappers (not so
much if you use inlined functions). This approach would not suffer the
loading penalties described above.

OPTION 3: Writing a boost XML/XPath parser would allow the internal
structure to be optimised for C++-specific bindings, while not suffering
from either wrapper performance penalties nor document loading/SAX parsing

>What I had (and still have) in mind is a C++ interface to an existing
>implementation (libxml2 actually).

What if the user wants an interface to another implementation? Is it
possible to standardize access to other parsers.

NOTE: If you are using the option 1 approach, the variations would occur in
boost::xml::dom::document - specifically the constructor and the semantics
for BuildXMLDOM.

>Also I'm not convinced that the main goal should be to conform with
>the DOM specs as provided by w3c. Lots of implementers / users consider its
>design broken. Instead I'd suggest to try to come up with a 'good' C++ API,
>and then build a wrapper around it that provides the legacy
>mapping as needed.

This is the thinking that I have moved towards, more details of which can be
found in my last post on the subject.

NOTE: Here and in my previous post, I use DOM to refer to the C++ Document
Object Model binding, and not the W3C DOM standard. when I refer to that, I
use the W3C to specify what type of DOM it is.


Get Hotmail on your mobile phone

Boost list run by bdawes at, gregod at, cpdaniel at, john at