Open source validating xml parser
Using the test driver and the OASIS tests, a report is generated for each processor.That report summarizes the results for over one thousand test cases.The driver reads the test database, applies it to the processor under test, and writes out a detailed report. Such reports are valuable to developers who can use them to identify bugs that must be fixed without needing to look at perhaps hundreds of test cases.They are also useful to anyone who wants to evaluate a parser for use in an application.This structure came from basic principles of software testing, and from the content of the XML specification itself.Read the test documentation for full information, and for a brief summary just understand that: The information in the test report for a given XML processor can accordingly be quite complex.One basic issue is the lack of a standard for getting a DOM tree from a given document; there is also no standard way to report parsing errors, or to choose whether to continue processing after a validity error.DOM is also less widely supported than SAX.) The first draft of the OASIS report has some bugs in its test database.
The work of applying those tests, and evaluating their results, was intentionally left separate.
While that suite has only been published relatively recently, many of its key components have been well known to the XML community for over a year and a half; they shouldn't come as a big surprise for any implementor.
Many of these tests have been used for basic quality testing in a variety of XML processors.
One indication of XML's success is that a dozen or so implementations of an XML processor exist.
These processors, spanning a variety of programming environments, are at the core of a new generation of web tools that are revolutionizing the dynamic generation of HTML and enabling new types of web applications, including business-to-business data messaging.