Re: [gdome]Introductory questions: ref counting, libxml access

[Luca Padovani <lpadovan cs unibo it>]

Hi Bret,

On Wed, 2002-09-04 at 00:22, Bret Taylor wrote:
> 1. What gets freed with gdome_di_freeDoc? Basically, I would like to
> avoid the explicit reference counting if possible: parse a document, use

gdome2 reference counting mechanism is very annoying to use (in C), but
it is a fundamental "feature" of the library, especially if you think
that in most cases Gdome2 is not used as is. All the wrappers for Gdome2
I know of hide reference counting: Perl, Ruby, Ocaml, C++.

> 2. The DOM implementation seems refreshingly complete, but many
> operations in other libraries require libxml structures (for example,
> XSLT and XPath). I would like to be able to use a DOM document and then
> transform it without reverting to non-portable hacks like copying the
> gdome-xml-*.h data structures. Is there a method to get the underlying
> xmlNodes that I am missing?

you don't need to. We have developed a library that does this already:

	http://www.cs.unibo.it/helm/gdome_xslt/

there are C/Ocaml bindings. I believe there are also Debian packages for that.
The reason why this piece of code is not inside Gdome2 itself, is that the
XSLT transformation API is not part of the DOM standard yet, and we wanted to
evaluate the code before making it part of Gdome2. As Daniel pointed out, it
is not that straightforward to define an API for XSLT which is complete and
flexible for everybody. Furthermore, exactly as libxml2 and libxslt are shipped
as separate libraries, we wanted to keep gdome2 smaller (and with fewer
dependencies). Inside Gdome2 there is a complete implementation of the DOM
Xpath module.

> 3. Is there a method to convert from an xmlDoc to a DOM document, and
> xmlNode to a DOM element, etc.?

yes, this is possible. But before doing so think about it twice.
gdome_xslt and the xpath module already do this dangerous conversion. If
users keep using the libraries and the modules, they don't have to mess
around with gdome2 internals (which are likely to change as libxml
evolves).

Cheers,
luca