xml.testing
Class Driver

java.lang.Object
  |
  +--xml.testing.Driver

public class Driver

extends java.lang.Object

Runs a SAX (preferably 2.0, but alternatively 1.0) parser through its paces by using a parser conformance test suite.

The test suite must conform to the DTD defined by the NIST and OASIS XML Conformance test suite, available at http://www.oasis-open.org/committees/xmltest/testsuite.htm. As of this writing, the current draft is 12 July 1999, and a "feb05.tar.gz" update (to one set of XML 1.0 errata) behaves reasonably well. (Note that some versions of ZIP are known to corrupt the test data; don't use them to extract files from any of the XML test databases.) The "March 15, 20001" update, to test the second edition errata set, is currently known to have some bugs (at least some missing files); be careful what you test against.

This reads the test suite database into memory (using the reference SAX2 implementation Ælfred2) into memory and then uses that database to drive the five types of tests defined by the NIST/OASIS framework. The results of those tests are printed as valid XHTML, mostly as tables, which may then be viewed using most web browsers. The XHTML is currently generated through a document template.

Version:

$Date: 2001/04/29 17:44:15 $

Author:

David Brownell (dbrownell@users.sourceforge.net)

Method Summary

static void

main(java.lang.String[] argv) Generates a conformance report using a given test suite and report template, for a specified SAX parser.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Method Detail

main

public static void main(java.lang.String[] argv)

Generates a conformance report using a given test suite and report template, for a specified SAX parser. The report will appear on the standard output, in US-ASCII encoded XHTML.

Command line parameters are, in order:

• Filename or URL for test suite's XML data;
• Name of SAX parser being tested;
• Filename or URL for report template.
• [IN FLUX] -- "nv" or "val", ignored (see -D...validation)
• (optional) parser descriptive string

See the associated report template for information about the syntax used there; a number of XML processing instructions are used to indicate that this driver should substitute certain data in the template, such as tables of test results or data about the test run used to generate the report.

If the parser supports the SAX2 feature API, it is queried for validation, external-general-entities, and external-parameter-entities support. If that fails (perhaps because the parser does not support SAX2), then three system properties are used instead. These all share a common prefix, xml.testing.Driver., to which are appended validation, general-entities, and parameter-entities respectively. (The only legal values for those properties are "true" and "false".) This driver must be able to determine whether the parser being tested parser performs XML validation, else it can neither test nor report correctly.

Some SAX2 parsers will be able to set those three features. If that is the case, this driver can use the system properties noted above to determine the value the feature should be assigned. For example, if a parser can validate, it will have a default value for the setting of its validation feature. If that isn't the intended value, then the feature value can be changed by setting the appropriate system property value.

Some parsers have been observed to have severe failure modes (notably, infinite loops) triggered by some test cases. So that test reports may still be generated for those processors, an exception mechanism has been defined to arrange that those cases are not run and are treated as failures. Using the same system property naming convention defined above, the exceptions string is appended to the common prefix. That names an XML file. Within that file are <EXCEPTION ID="..."> elements; the ID value is the ID of a test which will be marked as failing without running it.