Beginning XML - Part IV(Basic Schema Of A DTD)

XML: Why It Matters and How It Keeps Data Clean

When you load a web page in a browser, the markup you see is mostly a series of tags that describe how content should be displayed. Those tags belong to HTML, a language designed to tell browsers how to render text, images, tables, and other visual elements. XML, on the other hand, was created to describe data itself, not how it looks. This separation means that an XML document can hold structured information - such as a customer record, a purchase order, or a set of research results - without telling a browser how to present it.

Because XML stores only the data and not the visual instructions, it can be reused in a wide variety of contexts. A single XML file can feed a website, populate a desktop application, or be the payload of a web service call. It is the same data, independent of the device or platform that consumes it. That independence is what makes XML attractive for data exchange between organizations that use different software systems.

Consider a company that runs a mainframe database with legacy customer records. If that database stores information in a proprietary format, the data is locked inside that system. With XML, the same data can be exported into a plain text file that any system can read. An online retailer can pull that XML file, validate it against a shared schema, and load it into its own database without having to rebuild a custom integration layer.

XML’s portability is not limited to files on disk. The protocol that transports data over the web - HTTP - works the same way with XML as it does with HTML. Because XML is just text, it can travel across firewalls, be cached by intermediaries, and be encrypted if needed. Clients that receive XML can parse it into in‑memory objects, manipulate the data, and render it in whatever view they prefer - table, graph, or interactive form - without needing to hit the server again.

The ability to merge data from different sources is another benefit. Suppose a research institute receives experimental results from several laboratories. Each lab writes its data in its own custom format. By defining a common DTD (Document Type Definition) or XML Schema, the institute can transform each lab’s output into a single XML representation. A validation step ensures that every record conforms to the agreed structure, eliminating errors that would otherwise arise from manual merging.

Beyond data exchange, XML helps teams keep a clear boundary between user interface code and business logic. Developers can create a set of XSLT stylesheets that transform raw XML into HTML for a web page. Designers can tweak those stylesheets without touching the underlying data logic. If the underlying data changes - say a new field is added - the stylesheets can be updated to expose that field. This flexibility encourages a modular architecture where changes in one layer do not ripple through the entire system.

Because XML files are human readable, they also become good documentation. A carefully written XML file that includes descriptive element names and comments can serve as a living contract between teams that need to exchange data. When a client receives an XML file, it can open it in a text editor and immediately see what information is present and how it is structured.

In short, XML lets organizations move away from tightly coupled systems where presentation and data are inextricably linked. It offers a lightweight, text‑based medium that remains readable, transmittable, and extensible across platforms. The rest of this article dives into one of XML’s oldest tools for enforcing structure: the Document Type Definition, or DTD.

Defining Structure with DTD: From Concept to Validation

A DTD is the original mechanism that XML provides for declaring the structure, allowed elements, and attributes of an XML document. Think of it as a blueprint that tells an XML parser what the document should look like. The parser can then read an XML file and verify that it matches the blueprint before any application consumes it.

DTD syntax is fairly straightforward. A DTD can be written inline inside an XML file as a Document Type Declaration, or it can be placed in a separate file with an .dtd extension and referenced from the XML. In both cases, the DTD lists the root element, its child elements, the order of those children, and any attributes they may have. It can also define the data types for those attributes - whether they are required or optional, and whether they should be a simple string or a number.

Here’s a concise example that illustrates the key parts of a DTD for a simple catalog of books. The root element is catalog. Inside catalog, we allow any number of book elements. Each book must contain a title, an author, a price, and an optional genre. The book element itself has a required attribute called id that uniquely identifies the book. The DTD also declares that price must contain a decimal number.

Each line in that snippet has a purpose. <!ELEMENT catalog (book+)> tells the parser that the root catalog element must contain one or more book elements. The book+ notation means “one or more” occurrences. If the document had zero book entries, the parser would flag an error.

The book element declaration follows a similar pattern, specifying that a book must contain exactly one title, one author, one price, and optionally one genre. The question mark after genre indicates that it can appear zero or one time.

Next, the ATTLIST section declares attributes that belong to an element. For book, we specify an attribute named id of type ID. The ID type guarantees uniqueness across the entire document, making it perfect for referencing items later. The #REQUIRED marker means that every book must have an id attribute; a missing id will trigger a validation error.

The remaining element declarations, such as <!ELEMENT title (#PCDATA)>, indicate that the element can contain parsed character data (plain text). In this simple DTD we treat all text nodes as strings; more advanced DTDs can specify other types, but those are less common today.

Once the DTD is in place, an XML document that references it can be validated automatically. For example:

Running this file through an XML parser that supports DTD validation will confirm that the book element has all the required child elements, that the id attribute exists, and that the price contains numeric data. If you, for instance, omitted the price element, the parser would report an error and refuse to continue.

Because DTDs are independent of any particular application, multiple teams can agree on a shared DTD and use it across their systems. One company can produce XML files that conform to the DTD; another company can consume them, confident that the data will adhere to the agreed structure. This reduces the friction that normally arises when integrating heterogeneous software.

Despite the rise of XML Schema (XSD), DTD remains in use because of its simplicity. Many lightweight tools and older systems still expect a DTD. Learning DTD concepts also gives a solid foundation for understanding XML validation in general.

To sum up, a DTD is a declaration of structure that lets you enforce consistency across XML files. It is the first line of defense against malformed data and a bridge between different teams that need to exchange information reliably.

Amrit Hallan is a freelance copywriter and website content writer. He also dabbles with PHP and HTML. For more tips and tricks in PHP, JavaScripting, XML, CSS designing and HTML, visit his blog at http://www.aboutwebdesigning.com.