Re: [boost] RFC: Boost.XML API prototype in the sandbox

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-07-12 13:24:52

Phil Endecott wrote:

...

> As gchen writes: "creating xml does't seem a big problem, but writing 
> xml-reader
> [..] is a time-consuming task".  Boost.Spirit can match things; can we use 
> something
> vaguely like Spirit syntax to match XML fragments, and define actions to 
> apply
> to them?

...

You can do that in principle. In practice I've been using a mirror approach 
of the write example in my other mail, with 'add_element' replaced with 
'get_element', and a bit of error checking thrown in. It's a bit like 
writing recursive descent parsers by hand, only much, much easier. I can 
post an example if you like.

> Peter Dimov also wrote:
>> Doing an XSL transform on a "virtual" document would require an
>> abstract node interface that you implement on top of your existing
>> data to provide an XML view for it
>
> I wonder if any serialisation or introspection experts have any
> suggestions?

Neither serialisation nor introspection is what you need here. The idea is 
that you have a foreign data structure and you need to present it as a 
virtual XML document with a predefined schema. In general, if you reflect or 
serialise the structure, you'll get XML that doesn't match the schema you 
need.

Let's say that you have

map< string, pair<string, string> > m;

and you want to present it as

<data>
    <item id="x1">
        <foo>...</foo>
        <bar>...</bar>
    </item>
    <item id="x2">
        ...
    </item>
    ...
</data>

To achieve the mapping, you'll define data_element, item_element, 
foo_element and bar_element, each of which points to its corresponding C++ 
equivalent. data_element will store a pointer to the map, item_element will 
store map::iterator, foo_element and bar_element will store a pointer to 
std::string. For maximum benefit the XML node abstraction needs to be 
written carefully, though; it must not make implicit assumptions that the 
nodes always exist in memory.

(Even if it does you'll likely need to only keep the node path in memory and 
not the whole tree, though.)