Why create a new vocabulary?

Now that we've seen how to create a custom language (vocabulary) with XML, let's ask why we need to do so (funny how things always seem to happen in that order). So far, everything that we've done in this article can be, and is, done using more traditional tools, without the need for DTDs or even XML. Why re-invent the wheel?

The answer is that in computing, the issue is often not just how to do something that couldn't be done before. Merely to do the same thing in a simpler and more flexible way is often a worthy goal. Disseminating information on the Web is superior to writing the information on pieces of paper and sending them around via carrier pigeons, although the end result may be the same. A custom XML vocabulary can be used to do some of the same things that formerly had to be done with cumbersome and slow scripting languages.

In the above data-validation example, a plain XML document (sans schema) could be linked to a validation routine written in Perl or JavaScript, as many HTML forms are. But this is a bandwidth-inefficient way of doing things, and it requires the validation routine (or a link to it) to be included in every document that allows a particular type of data to be entered. With an XML schema, the validation is an integral part of the element itself. Applications that access this data need not include their own error-checking routines, saving a lot of programming effort.

For a meatier example of how a specialized XML vocabulary can get things done more efficiently, let's extend our earlier LIST and ITEM example.

Let's say we have a very modern and efficient fruit stand, and that detailed information on the fruit in our inventory is stored in a legacy database. Now we want to create a Web-based interface to this database. Using a DTD and/or a schema, we create a vocabulary which we'll call FML (Fruit Markup Language). FML includes elements which correspond to the (already existing) field names in our database:

• NAME
• COLOR
• PRICE
• SOURCE

A scrap of XML code describing a banana might look like this:

<ITEM>
<NAME>
Banana
</NAME>
<COLOR>
Yellow
</COLOR>
<PRICE>
50 cents US
</PRICE>
<SOURCE>
Costa Rica
</SOURCE>
</ITEM>

This begins to look like a database, with ITEMs as "records" and the other tags as "field" delimiters. Aha! This is one of the greatest benefits of XML - it allows data to be organized in a hierarchical way, with relationships among data clearly and easily expressed.

Now it's easy to create a Web-based interface that allows the user to specify which fields (elements) are to be displayed, or compiled into a report. When we defined our own elements, we gave them names that corresponded to the already existing field names in our legacy database, making the code easier to edit, and quite possibly saving a translation step.

A Web database interface like the one hinted at above could not be created with HTML alone, nor was HTML ever designed for such purposes. HTML could be used to control the format of such a thing, but for the "guts" of it, one would need to use a scripting tool such as Perl, JavaScript, ASP, Java, etc., with all the issues of bandwidth, cross-platform compatibility, browser capabilities and such that go along with it.

This is just one tiny example of how XML enables simple, elegant solutions to computing problems. When we run into something we can't do with existing XML (as with the DTD issues discussed earlier), we simply extend the language to take care of it.

For Further Reading

WDVL's XML Section

http://www.dtd.com
Scads of publicly available DTDs, plus info on how to create your own.

How to Create a Vocabulary
Building Languages with XML