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.
<!DOCTYPE case_summary SYSTEM "case_summary.dtd"> line specifies
the external DTD to use. The case_summary.dtd file would contain the following
Some obvious targets for testing include that:
- the mandatory fields are present
- there cannot be more than one
- there must be at least one
casenode, within the
code_valueattributes 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
node is present, but it does not contain any cases:
Validating an XML 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.