DTD for Qualified Dublin Core -- DRAFT PROPOSAL 2002-12-12, TGH

Summary of DTD

The following DTD was developed primarily as an intellectual exercise, but also to examine the suggestion that any Guidelines for Dublin Core in XML should be implementable as DTDs, at least as a baseline. Related to this, the DTD explores whether the use of the xsi:type attribute too closely ties the Guidelines to the XML Schema language. This DTD was influenced by work done on the Recommendations for XML Schema for Qualified Dublin Core.

I believe the following DTD conforms to the Guidelines for implementing Dublin Core in XML in all respects, except, of course, for the first Recommendation to use XML Schemas instead of DTDs. This includes the somewhat controversial Recommendation 7 to use an xsi:type attribute to express encoding schemes.

Miscellaneous Features of the DTD

• DTDs do not have any built-in support for namespaces. This requires the use of some fairly convoluted techniques in order to support namespaces in as flexible a manner as possible. This DTD makes extensive use of parameter entities to does this, including some non-obvious parameter entity 'tricks':
  • Because of how parameter entities are expanded it is impossible to create an element name by concatenating parameter entities. For example, in order to create a <dc:title> element it is tempting to use something like <!ELEMENT %dc_prefix;:title (#PCDATA) >, but this is not legal. However, you can concatenate parameter entities to create new parameter entities; thus, <!ENTITY % dc_title "%dc_prefix;:title" > is legal. This then allows <!ELEMENT %dc_title; (#PCDATA) >. This technique was used through the DTD. For an explanation of this see 4.4.8 Included as PE in the XML standard.
  • By using parameter entities to define namespace prefixes, the root element name, and so forth, it is possible for document authors to override these values by using an internal subset of the DTD in the document instance. This is done in the test.xml document to customize the namespace and element name for the root element. It could also be used to customize the value used for the DC namespace prefixes. The DTD does define default values for namespaces, the root element, and so forth, so using an internal subset is strictly optional for authors who need the added flexibility.
  • It would be possible to use XML Conditional Sections to make the DTD even more flexible, for example to allow the inclusion of Qualified DC to be turned on or off as desired. This has been left as an exercise for the interested reader (if anyone actually reads this far :-)
• DTDs have extremely limited support for datatyping, making it essentially impossible to enforce any datatype constraints other than simple PCDATA via a DTD. This includes any constraints that might be associated with the various encoding schemes.
• For maximum flexibility, namespace declaration attributes, such as xmlns:dc="http://purl.org/dc/elements/1.1/" have been included as #FIXED attributes on every element, including the root element. In typical instance documents these are only included one time on the root element, but it is also legal to repeat them on every element, if desired. One side-effect of making these attributes #FIXED on every element is that the instance documents can look very verbose in some viewers even when these attributes are really only included once in the instance document.

The DTD and Associated Files

dublincore.dtd

This is the main DTD. It defines the default namespace prefixes, the root element, standard attributes, and the allowed encoding schemes.

dc.ent

This entity file is included in the main DTD. It defines all of the elements included in the dc namespace.

dct.ent

This entity file is included in the main DTD. It defines all of the elements included in the dct namespace.

test.xml

Sample file which can be validated with the DTD.

Conclusions

While certainly not as powerful or as flexible as using XML Schema, it is possible to create a somewhat useful DTD that conforms to the Guidelines for implementing Dublin Core in XML (excepting Recommendation 1), including Recommendation 7 for using xsi:type. I personally would never use this DTD unless I was in a severely constrained environment where using XML Schema was impossible. This should be pretty rare with the wide adoption of XML Schema in a number of free and commercial implementations.

Another point is that the xsi:type recommendation can be implemented using a DTD, and if you want to support namespaces in the DTD anyway, adding support for this attribute isn't even difficult. Granted, in the DTD world you don't get any benefit from using xsi:type over any other arbitrary attribute name, such as schema, but my feeling is that the extra power and flexibility (of extensibility and datatyping capabilities) that using this attibute affords in the XML Schema world outweights the minor incovenience that implementing it in non-XML Schema environments might entail.

Coming Next

A Schematron implementation