Re: Re: LibxmlJ formalities

Julian Scheid <[email protected]> writes:

> 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?

No... you just send them to the office. I'll dig out the address for
you at some point. If I haven't done it by next week (I'm _really_
busy at work, hence I'm up at 1:15 am) then send me a reminder and
I'll do it on the spot.

 
> 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.

I'm fine with that. I think there's room for both. Particularly as
gcj is natively compiled.


> 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'm aware of the issues. Even to get a decent mapping from java IO
looked to be hard or crap (either frig the libxml2 source code so
that it genuinely supports a modular IO API or just spit the stream
into memory or a file - ugh).


> 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.

I hadn't realised there were thread issues. From what I've seen it
looked ok on that front. Can you include me on your correspondance?
I'd like to be involved.


> 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.

This is why I'm interested in it. I think it's probably the right
thing for a GNU java platform (where we don't necessarily care about
portability).

 

Nic