SAXON DTDGenerator
A tool to generate XML DTDs
Purpose
DTDGenerator is a program that takes an XML document as input and produces a Document
Type Definition (DTD) as output.
The aim of the program is to give you a quick start in writing a DTD. The DTD is one of
the many possible DTDs to which the input document conforms. Typically you will want to
examine the DTD and edit it to describe your intended documents more precisely.
The program is issued as part of the
SAXON product.
See the SAXON
home page for download instructions.
This version of DTDGenerator runs as a SAXON application, though in fact it exploits very few
SAXON features. A more recent version of DTDGenerator, which is considerably faster, has been
rewritten as a free-standing SAX application: this is available at
http://saxon.sourceforge.net/dtdgen.html.
Usage
First install SAXON. Make sure that SAXON, and the directory containing the DTDGenerator
class are all on the class path.
From the command line, enter:
java DTDGenerator inputfile >outputfile
The input file must be an XML document; typically it will have no DTD. If it
does have a DTD, the DTD may be used by the parser but it will be ignored by the
DTDGenerator utility.
The output file will be an XML external document type definition.
The input file is not modified; if you want to edit it to refer to the generated DTD,
you must do this yourself.
What it does
The program makes a list of all the elements and attributes that appear in your
document, noting how they are nested, and noting which elements contain character data.
When the document has been completely processed, the DTD is generated according to the
following rules:
- If an element contains both non-space character data and child elements, then it is
declared with mixed element content, permitting all child elements that are actually
encountered within instances of that parent element.
- If no significant character data is found in an element, it is assumed that the element
cannot contain character data.
- If an element contains child elements but no significant character data, then it is
declared as having element content. If the same child elements occur in every instance
of the parent and in a consistent sequence, then this sequence is reflected in the element
declaration: where child elements are repeated or trailing children (only) are omitted
in some instances of the parent element, this will result in a declaration that shows
the child element as being repeatable or optional or both. If no such consistency of
sequence can be detected, then a more general form of element
declaration is used in which all child elements may appear any number of times in any
order.
- If neither character data nor subordinate elements are found in an element, it is
assumed the element must always be empty.
- An attribute appearing in an element is assumed to be REQUIRED if it appears in every
occurrence of the element.
- An attribute that has a distinct value every time it appears is assumed to be an
identifying (ID) attribute, provided that there are at least 10 instances of the element
in the input document.
- An attribute is assumed to be an enumeration attribute if it has less than ten distinct
values, provided that the number of instances of the attribute is at least three times the
number of distinct values and at least ten.
The resulting DTD will often contain rules that are either too restrictive or too
liberal. The DTD may be too restrictive if it prohibits constructs that do not appear in
this document, but might legitimately appear in others. It may be too liberal if it fails
to detect patterns that are inherent to the structure: for example, the order of elements
within a parent element. These limitations are inherent in any attempt to infer general
rules from a particular example document.
In general, therefore, you will need to iterate the process. You have a choice:
- Either edit the generated DTD to reflect your knowledge of the document type.
- Or edit the input document to provide a more representative sample of features that will
be encountered in other document instances, and run the utility again.
In a few unusual cases DTDGenerator will create a DTD which is invalid, or one to which
the document does not conform.
You will then have to edit the DTD before you can use it. The known cases are:
- An attribute can only be declared as an ID if all its values are valid XML names,
and as an enumeration type if all its values are valid XML NMTOKENs. DTDGenerator only makes a
partial check against this condition: in particular, it only rejects values that contain
ASCII characters that cannot appear in names (e.g. space).
- DTDGenerator will decide that an attribute is an ID attribute if all its values are
distinct, without checking whether the set of values overlaps with those of another
ID attribute. In some cases this results in an IDREF attribute being incorrectly classified
as an ID.
Michael H. Kay
10 August 2003