Testing your DTD XML Schema Validation | WebReference

Testing your DTD XML Schema Validation

By Rob Gravelle


A Document Type Definition (DTD) document is used to define the legal building blocks of an XML document. It denotes the document structure with a list of legal elements and attributes. DTDs are often used to facilitate agreement on formats for data interchange between independent organizations or people. Thus, your applications can use a standard DTD to verify that the data you receive from the outside world is valid or to verify your own data, before sending it out to partners. Whatever your reason for using a DTD, it's important to thoroughly test it, like any part of a business process, whether automated or not. A key ingredient of successful testing is the separation of the component that you are testing from the rest of the process or application. With that in mind, this article explains how to perform your DTD testing outside of the application that runs it.

Before we begin, this article assumes that you have a working knowledge of both XML and DTD validation. In case your memory needs refreshing, WebReference has plenty of information on both XML and DTD.

The XML Test Data

Most of the time you'll need several XML files to test all the permutations of the data's structure. For instance, a node that may contain one or more children requires three cases: one without children, one with exactly one child, and one with several children. Make sure to give each of these files an adequately descriptive name so that you can easily identify the one that triggered a DTD validation error - something like "invalid_case_summary_no_case_node.xml". You'll also want to separate the test cases into two categories: those with valid structure and those which are invalid.

To begin, let's assume that you had created the following XML document to define the data structure of a "case_summary":

The <!DOCTYPE case_summary SYSTEM "case_summary.dtd"> line specifies the external DTD to use. The case_summary.dtd file would contain the following element definitions:

Some obvious targets for testing include that:

  • the mandatory fields are present
  • there cannot be more than one case_list, given_name, or date_of_birth nodes
  • there must be at least one case node, within the case_list element
  • the code_value attributes are populated

The first XML documents that we procure will act as our model and will adhere to all of the format rules outlined in our DTD. If you are dealing with an outside partner, you may have some ready-made files at your disposal; otherwise, you must create them yourself. Here is a document that would satisfy all of our formatting rules:

Once you've covered all the bases, you may proceed to procure or create documents that do not meet your criteria. In the following XML document, the case_list node is present, but it does not contain any cases:

Validating an XML Document

To test an XML document, we need to create a stand-alone XML parser that can provide information whenever an error is encountered. Microsoft has a number of ActiveX libraries for this purpose. Using JavaScript, we can create an instance of the library and parse the document:

The above script accepts the XML file name via a prompt dialog. Upon receiving the file name, it proceeds to create the XML parser object and load the document into memory. The validateOnParse property is set to true to make sure that the validation is performed while the document is loaded. We can then check to see whether or not the parser's parseError object contains a trapped error. Our script displays three parseError properties: the error code, the reason and the line number. See this Microsoft article for the full list of available properties.