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/
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format