Re: [Libxmlplusplus-general] API questions

[Stefan Seefeld <seefeld sympatico ca>]

Murray Cumming wrote:

[ xpath based lookup ]


> > What is needed for this is 1) a document to search in, 2) a
> > context node, 3) the actual xpath expression.
> >
> > Would you be interested into a patch that adds
> > such functionality ?
>
>
> Absolutely.

Great, I'll come back to you shortly.


> We use pointers everywhere else at the moment.

hmm, isn't that dangerous ? I don't know libxml2's ownership
semantics well, so I don't know who is responsible for child
node cleanup etc.
Imagine you have two xmlpp::nodes, with a parent/child relationship.
Then you delete the parent, calling the underlaying libxml2
cleanup function (which, let's say, cleans up the subtree recursively).
Your child xmlpp::Node now points into invalid memory !

I would suggest you fix the semantics and then implement that
appropriately, either by always using deep copies, or (probably better)
by means of smart pointers (ref counting).

> Feel free to patch to create the Document abstraction.

ok. That won't be much more than a refactored DomParser. At least
for a start.

> > 2) For various reasons I think nodes should hold a reference to
> >    the document they are part of. This is important as soon as
> >    you want to interpret them, for example namespaces can only
> >    looked up in the document, the same is true for default attributes
> >    (defined in the dtd).
> >    Assuming the node knows its document, the above 'lookup' method
> >    could be written more naturally as
>
>
> If this is necessary then it sounds OK, though there might be some
> circular-reference complications.

actually, I think the libxml2 node types already contain pointers to
the document. But right now your xmlpp::Node class isn't implemented
in terms of libxml2 types. Why ? As I understand, libxml++ is a wrapper
around libxml2. If this is true, you should always delegate down to
libxml2. Specifically, xmlpp::Node should simply hold a (private)
xmlNode pointer, from which the document can be fetched.

> UTF8 has variable numbers of bytes per character, so wstring is no good:
> http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch03s04.html

hmm, ok. What about parametrizing the whole libxml++ for the char type
to be used ? That would work similarly to std::string and std::iosream,
i.e. you would write a 'trait' that provides the mapping for application
specific string classes.

That would avoid to drag in any new dependency on things such as glib, while
avoiding the need to rewrite the code.
I don't know how difficult that is. The best thing would be to analyze
the methods and classify them into those that depend on the character type
and those that don't. The ones that don't could go into simple base classes,
and the rest would go into templated derived classes (those methods then
need to be inlined, so they should be short).

Well, I hope this all doesn't sound too invasive, I'm just trying to figure
out how to make libxml++ more useful and feature-complete while keeping it
simple. Please bear with me...:-)

Kind regards,
		Stefan