Call for fast XML implementations

Dear all,

it's an interesting coincidence that at the same time that the EXI WG  
was busy drafting this very email xml-dev was discussing faster XML  
parsers. We're sorry to say that we don't have money to offer, though  
we can offer warm fuzzies and the chance to get your implementation  
before the eyes of XML-related decision-makers (or at least  
influencers) from quite a fair number of companies.

As you may know, the Efficient XML Interchange WG has been busy  
building up a framework for the purpose of measuring various aspects  
of efficient XML formats, with the goal not only of comparing  
efficient formats with one another but also of comparing them to XML  
in order to demonstrate the need for such a format with the nitty- 
gritty of detail that has been requested of us. It is notably of  
interest because these measurements will constitute a go/no-go point  
such that if the efficient formats are not efficient enough, the EXI  
WG would be closed down without producing an efficient XML format.

Needless to say, performing this comparison against a set of sluggish  
XML parsers out there, of which there is no shortage, would hardly  
prove satisfying. We therefore plan to use the fastest XML parsers  
that we can lay our hands on, and this is where you can help us.  
While the WG does have quite a fair bit of experience looking for  
faster XML parsers, we do not claim to have perfect, all-encompassing  
knowledge about the options that may be available and that we might  
have overlooked in the past few years. Furthermore, a non-negligible  
number of the XML parsers that are pitched as faster than the rest  
achieve these levels of performance by cutting corners, generally  
making them non-conformant — something which we cannot consider to be  
a valid approach.

Therefore we solicit input from the community regarding fast XML  
parsers. Which one(s) would you pick if you had to tear through XML  
documents at warp speed? What is your experience with them in terms  
of conformance? What would be your best bet if you wanted to kill the  
EXI effort in its tracks?

We will naturally accept any and all information that we get our  
hands on, but in order to be able to make the best use of the  
information and possibly to avoid being swamped, there are some  
aspects that we would like to see alongside parser recommendations:

  * Some form of conformance statement. It needs to pass the XML Test  
Suite (http://www.w3.org/XML/Test/).
  * We need to be able to actually measure it. This entails that if  
the code is not publicly available, we'll need a way to work out how  
we can get a copy of the code to run it in our test system. This  
doesn't necessarily mean making a copy of it available to all members  
of the WG, but at least to the W3C staff so that they can run the tests.
  * If you wish to be extra helpful, you can also include the small  
amount of code and configuration required to run the parser within  
our framework, which is built on top of Japex (https:// 
japex.dev.java.net/). If you're interested, we'd be delighted to help  
you get started.

Thank you very much in advance, we look forward to your input.

-- 
Robin Berjon, on behalf of the EXI WG
    Senior Research Scientist
    Expway, http://expway.com/

Received on Friday, 24 March 2006 18:17:13 UTC