About kXML

The kXML project provides an XML pull parser and writer suitable for all Java platforms including the Java 2 Micro Edition (CLDC/MIDP/CDC). Because of its small footprint size, it is especially suited for Applets or Java appications running on mobile devices like Palm Pilots or MIDP enabled cell phones

kXML was originally developed at the AI Unit of the University of Dortmund as a "side product" of the COMRIS project. In the COMRIS project, the API was used in the Information Layer module(s) to parse XMLified FIPA messages and to generate template based XHTML pages. The template based XHTML generation is currently used in the MLnet teaching server, too. kXML is also used in the Enhydra kXML-RPC and kSOAP projects.

kXML key features are:

• XML Namespace support
• "Relaxed" mode for parsing HTML or other SGML formats
• Small Memory footprint
• A Pull-based parser for simplified parsing of nested / modularized XML structures
• XML writing support including namespace handling
• Optional kDOM
• Optional WAP support (WBXML/WML)

As the software is completely open source, you can:

• Download binaries, samples, packaged source code, and Javadocs
• Browse the online JavaDocs
• Get the code from CVS
• Check out the kXML License

kXML contributors are:

• Bjorn Aadland
• Michael Angel
• Scott Daub
• Daniel Feygin
• Wilhelm Fitzpatrick
• Eric Foster-Johnson
• Stefan Haustein (chair)
• Brett McLaughin
• Paul Palaszewski
• Jörg Pleumann
• Hans-Harald Schulz
• Michael Wallbaum

What are the restrictions of kXML?

In order to keep kDOM small and understandable, support for some features declared harmful in the Common XML documentation is limited in kXML.

• kXML does not support user defined (external) entities.
• The doctype declaration is not parsed. However, a corresponding "legacy event" is generated by the parser, so application programmers are able to parse the doctype declaration themself

Why a PullParser? Why not SAX?

The most simple parser implementation follows a push model. Depending on the content of the document and the internal state of the parser, events like "startElement" or "characters" are sent ("pushed") to a document processor. However, from a document processor point of view, the push model causes some problems: In the event handling method, the processor always needs to perform some recovery in order to determine its own internal processing state before it can do anything with the event.

In contrast, when the parser is "pull"-based, the application is in control where it asks for the next event. The advantage is that the processing state can be implemented much more natural in local variables and recursions. Furthermore, a pull based parser can simply be handed over between different fragment processors, supporting simpler modularization and code that is more readable in many cases.

Why kDOM? Why not JDOM or the W3C DOM

The motivation can simply be taken from JDOM: XML processing in JAVA should be as simple as JAVA itself. The problem with JDOM is that it depends on many classes that are not available in the JAVA 2 Micro Edition. Whereas the goal of JDOM is simplification, kDOM tries to add a significant reduction of memory usage cruical on small devices like the palm pilot.