[Classpathx-discuss] Re: LibxmlJ formalities

[Julian Scheid]

Nic Ferrier wrote:
> If you want to do assign I'm affraid that you do need to do
> that. ClasspathX doesn't _require_ (c) assignment however, so it's
> not necessary in the short term.

OK, will keep copyright then for now. WRT the papers, is Paul Fisher
the right guy to ask?

> That's great.

Thanks, but let me scale down your expectations, and share a little
of what I've learned about libxml/libxslt during the last two weeks
or so.

First of all, I think I didn't mention it's transform-only. It's only
a partial implementation of JAXP, that of javax.xml.transform.**. And
no, it does not cooperate with Aelfred, as this project is intended
to be a JAXP wrapper for the full libxml/libxslt combo in the long
term. This means you can't share e.g. DOM trees between both Aelfred
and LibxmlJ.

You can use Aelfred and LibxmlJ in parallel, though. Works just fine
in the upcoming Gjdoc, where Aelfred is used to parse an XML file
produced by LibxmlJ (but via a stream detour).

Secondly, and more seriously, libxml2 is a b*** when it comes to
adapting it to JAXP. For example, there is no way to have URIResolver
get the correct href and base parameters, absolutely no way. Believe
me, I tried. I analyzed hundreds and thousands of lines of libxml
source code in the past week - no way, not even around three corners.

Note that I don't want to discredit the work of the xmlsoft people.
Libxml and libxslt are fast, reliable, standard-compliant and mature.
It's just that their backend API is not as detailled and coherent as
I'd hoped it were.

I think to be able to create a 100% JAXP compliant, reentrant wrapper,
Libxml2's API would have to be so severely extended and rewritten that
it would afterwards better be called Libxml3. No kidding. This means
there won't be a remedy for many problems in LibxmlJ in the near
future.

But LibxmlJ works fine for Gjdoc, it's fast as hell compared to Xalan,
and AFAICT it's the only way to wrap the latest JAXP-only Gjdoc into
an executable, because Xalan doesn't play nicely with gcj.

I'll have to talk to Daniel Veillard and the other Libxml developers
and check with them which of these problems can be addressed in order
to provide a sufficiently complete, reliable, ideally multi-thread-
supporting JAXP transform implementation.

So for now, everyone should consider this a hack, because that's what
it (necessarily) is. Not suited for Application Servers or such, but
may help with relatively simple, single-threaded XSLT applications
like Gjdoc. See BUGS in the forthcoming CVS module for more details.

On the bright side, and not surprisingly, gcj-compiled Java using
libxml/libxslt for XML processing is RAT fast and seems to exhibit
a low memory footprint compared to Xalan or other pure-Java
solutions.

> Hopefully, I'll now find the time to contribute to gjdoc.

That would be cool. I've been working on LibxmlJ and Gjdoc in
parallel, let me check in my local status before you start hacking
away.

Julian