Although suitable for validating the structure of an XML document, the DTD has nonetheless a number of important limitations.

Firstly, although it allows validation of the required and expected structure of a document, such as the correct positioning and nesting of elements, it can say nothing about the validity of the content.

Taking a leaf from the database designer’s book, the XML schema adds also the concept of ‘data-typing’. This allows a designer to specify what a specified XML element should contain, for example a date, an integer within a particular range, just text. In addition, XML schemas can include user-defined datatypes, such as a Zip code specified in a particular format, a name from a predefined list or a product or reference code.

An information manager should avoid being embroiled in the details of schema design, but nonetheless maintain a high-level view of their development. What is important is to give your developers guidelines on the basis of clear and comprehensive analyses of your information and document types.

There are ongoing debates about whether document analysts and designers should now abandon the DTD completely in favour of schemas in one form or another. Without losing ourselves in the detail, a good reason for using DTDs would if an organization already had a substantial investment in SGML and associated tools. SGML tools validate conformity of document instances to their associated types exclusively by means of the DTD.

The second limitation – now no longer valid – is that the XML Schema standard has not yet been finalized, so that developers must hedge their bets for some time to come. If your organization is coming into XML ‘clean’, with little or no SGML legacy, it is probably better to opt for the more powerful schema.

The basis for all XML work is the XML standard itself. It can be used on its own to created the so-called ‘well-formed’ document that we mentioned briefly before.

It can also be used with one or more Document Type Definitions, or DTDs, to ‘validate’ that the way XML is used in a particular document conforms to the intentions and expectations of the user or document designer. In addition, DTDs serve to inform other potential users of the structure and possible internal constraints of a document, so that those users and automated processes can know what to expect.

The structure and syntax of DTDs are unusual within the family, as DTDs themselves are not written in XML, but instead employ the syntax of XML’s ‘parent’ standard, SGML (Standard Generalized Markup Language).

Many commentators and XML evangelists alike have been predicting the early death of DTDs, as they are considered to not ‘fit the picture’ of an elegant set of standards all written in XML. Such predictions have proved premature, largely because of the delays and controversies associated with the much-awaited ‘schema’ standard, and also the DTDs familiarity to those document-management specialists who cut their teeth on SGML.

To know what ‘XML can do for you’, you need to be aware of the range of XML standards that are available. Although there is an ever-increasing and bewilderingly interrelated range of standards, they fall into three broad categories:

• Infrastructure standards: the bedrock of the family, these are the standards that offer the basic building blocks, raw materials and infrastructure of any XML strategy
• Processing and management standards: these are concerned with actually ‘doing something’ with your XML content
• Output standards: these are concerned with delivering or displaying XML content to a specific end format, and usually represent the end of a processing chain

In addition, there are XML ‘applications’ – the application of XML to a particular end using a common vocabulary, whether to meet the needs of a particular business sector (insurance, manufacturing, public administration etc.) or to enable inter-operability in one form or another.

We will now take a brief look at the members of the family. The objective is not to gain the intimate knowledge of each standard that is necessary to start a development project, but rather to gain a high-level overview of the scope of the standards and their intended application to information management problems. These family members, unless stated otherwise, are published and maintained by the World Wide Web Consortium, W3C and published in the form of recommendations.

On its own, XML is nothing more that an alphabet and a syntax. The XML standard itself merely lays down the rules needed to create compliant XML documents. As we shall see, XML schemas offer a mechanism for laying down a vocabulary and a grammar to express your particular needs as ‘content models’. We are therefore not so interested in ‘raw’ XML as the particular ‘variety’ or dialect that we establish for a particular need.

This is an important issue for managers. You can develop vocabularies and grammars that let you describe and create XML entities as diverse as blocks of text, formatting rules, complex graphics, business rules or an application interface. This explains the power that XML offers for wide-scale interoperability.

Indeed, the ‘tricky bits’ in any XML strategy will not be the questions relating to understanding XML itself and having sufficient users and developers high on the learning curve. The hard work will come in agreeing standards and vocabularies and in document and information design considerations. These are policy rather than technical issues and have to be handled and answered by management, not by programmers or developers.

This point serves to underline the central message of this course:
Management needs to take the lead and stay ahead.