Re: [boost] API Review request: XML APIs for C++

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-13 12:53:40

Hamish Mackenzie wrote:

>>Yes, I can see that, for the xml node types. But for that we don't even
>>need anything but a single 'node_proxy' class (with a 'type()' method
>>returning an enum).
> 
> 
> True.
> 
> Though it might be useful in the next layer of the interface. If you end
> up with another proxy type that has lots of
> 
> switch( raw_node_.some_node_property() )
> {
> ....
> }
> 
> I use a very similar system in an HTML editor where the entity name is
> used to lookup the handler.

really the entire name ? Hmm. I'm thinking of the DOM spec(s), and
domain specific extensions. There typically new node types are
elements, i.e. they would (logically) all derive from dom::element.
(SVGElement, say).

Hmm, I'm not sure yet how to 'extend' dom::nodes towards these DOM
types. But it seems inheritance is not the right solution, especially
if we don't control the node's construction, i.e. we can't just plug
in a 'SVG node factory'.
Anyways, that's another layer...:-)

> Maybe we do need to allow the use of _private in higher level layers.

I don't think that's a good idea, in particular because it's to tightly
coupled to a particular implementation. We could allow a 'payload' for
nodes (possibly a template parameter), but we could as well do the 
association between a node and its template in an external lookup
mechanism, which seems to be more clean and drag in the least overhead.

>>I start to like your node reference class quite a lot... :-)
> 
> 
> I am definitely leaning toward "node_reference" rather than "node_proxy"
> is that your preferred name too? 

I was talking about your proxy approach as opposed to my node wrapper 
classes that are constructed on the heap.

But yeah, concerning the naming I prefer reference over proxy.

>>yeah, a parser for asynchronous document creation may be interesting.
>>But I see that as a somewhat different beast. Simple (local, 
>>synchronous) document creation from an xml file doesn't need to
>>go over a stateful parser object.
> 
> 
> Its not a high priority but it is nice that libxml2 supports it.  

Agreed. So we could have both, stateless (synchronous) parsers creating
a document in a single call, and statefull asynchronous parsers that
can be bound to event loops or other 'signals'.

Regards,
                Stefan