This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Default XML-parser implementation?


Hi,

On Tue, 2004-06-01 at 16:08, Michael Koch wrote:
> I think our preferred implementation is GNU jaxp (part of classpathx 
> project on savannah.gnu.org).

And Chris Burdess just send the attached announcement about libxmj.
You might want to join the classpathx-xml mailinglist.
http://lists.gnu.org/mailman/listinfo/classpathx-xml

Cheers,

Mark
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

We're making a lot of progress on libxmlj. For those of you who don't know what that is, it's a JAXP implementation that uses Gnome libxml2 and libxslt to do all the grunt work. It's usable now, and you can get it from jaxp CVS.

I've done a lot of conformance and performance testing. Conformance is against the W3C XML test cases. I've been using a 3rd-party test framework - http://cafeconleche.org/SAXTest/

Results for gnu.xml.aelfred2.XmlReader:

Passed 925 of 2162 tests.

Failed 1237 of 2162 tests.

Conformance level: 42.78%.

Results for gnu.xml.libxmlj.sax.GnomeXMLReader:

Passed 1626 of 2162 tests.

Failed 536 of 2162 tests.

Conformance level: 75.21%.

If anyone has about 400MB of spare webspace, I can upload the complete results showing what should have happened versus what did happen in each test.

Most of the libxmlj failures are in some way linked to the failure to provide correct callbacks for resolveEntity (I've talked to Daniel Veillard about this but still can't get it to work the way he says it does). As soon as that happens I expect a large jump up the conformance ladder. Even so it's not bad - remember that these test cases are all really marginal edge conditions. libxmlj is easily stable enough to do simple SAX and DOM parsing; for instance, I now use it as the parser for Ant.

In terms of performance, libxmlj easily outstrips aelfred2 even for tiny documents: on a simple document with one document element with one child element, libxmlj parses in 60-70% of the time aelfred2 takes, even with the overhead of loading the native library. On very large documents performance improves even more.

I need to fill in some of the less common parts of the API, and I want to have an XPath implementation, i.e. implement http://www.w3.org/TR/DOM-Level-3-XPath in libxmlj.dom, despite the fact it's not a standard yet. Based on discussions on the gcj mailing list, I should also store native pointers as jlongs in the Java classes (Julian did this originally but I stupidly moved to jints), and there are a few other things.

If anyone with some experience of libxml2 and/or libxslt would like to help, I can find tasks for them.

I'd also be interested in people's opinions about where we should be going with aelfred2 and the gnu.xml.dom classes.
- -- Chris Burdess
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)


iD8DBQFAtxa76dl1DEqHgrgRAkO7AKCGYjN8CX4iD+wzFy2A96hJ5FRhKQCdGLiv
9QcMKRAiBwc1KJWI6q7leL8=
=PRzu
-----END PGP SIGNATURE-----



_______________________________________________
Classpathx-xml mailing list
Classpathx-xml@gnu.org
http://lists.gnu.org/mailman/listinfo/classpathx-xml


--- End Message ---

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]