Web Techniques: Respecting Authority

Respecting Authority

By Michael Floyd

A cornerstone of XML development is the document type definition. DTDs let you model your data, define its organization and structure, and place constraints on its usage. In other words, DTDs let you define the schema for your documents. These schema can then be shared with others so that they can interpret the meaning of your elements and attributes, and more importantly, validate your XML data. Even when DTDs are not used in the actual processing of a document, they can be useful in documenting its element and attribute types. DTDs are also required if you go beyond the basics of elements and attributes and plan to use entity replacements, enumerated lists, or name tokens.

The problem with DTDs is that they aren't sufficient for describing data. Borrowed directly from SGML, DTDs use an extended Backus-Naur Form (BNF) syntax—a formal mathematical way to describe a language—that's sufficient for describing traditional document structures. Unfortunately, large-scale document management is not where XML has been popping up. Rather, XML is being used in lightweight applications to describe messages passed among applications, program structures, database tables, and even file formats. To describe such orientations properly, we need (at a minimum) the ability to associate data "types" with certain kinds of data. In other words, it's useful to distinguish a date from a string, or a floating-point number from an integer.

As you probably know, the XML Schema specification is nearing recommendation status within the W3C. Unfortunately, the recommendation has been slow in coming. In the meantime, companies like Microsoft have released interim implementations such as XML Data Reduced Schema (XDR) that do not (at the time of this writing) fully support the proposed recommendation. Also on the sidelines are other methods for describing schema, such as SOX and RELAX.

As XML application developers, this flexibility leaves us with several ways to define schema. You can use DTDs, Microsoft's XDR, the official XML Schema syntax, or one of several other methods. Even if your department standardizes on usage, other departments, subsidiaries, sister companies, and business partners are likely to define schema in other ways. Because schema are the primary means for sharing XML documents, this presents a serious roadblock.

That's where XML Authority (XA) from Extensibility comes in. (Visit Extensibility's site at www.extensibility.com for details.) XA is an XML schema design, conversion, and management tool. XA lets you import schema from different formats, work with them in a common environment using a common notation, and export them back out into any one of several formats. In addition, you can direct XA to create schema from data sources.

New Features

XML Authority supports the April 7, 2000 draft of the W3C XML Schema specification. The company says it is "committed to supporting this emerging standard and will continue to add additional support with each new release." Other features new to version 1.2 are an enhanced printing capability that lets you publish schema in various styles including content-model diagrams and hierarchical element views, improvements in the import facility, support for Software AG Tamino server, and the ability to export BizTalk version 1.0 XML documents.

Additionally, XA includes validation previews that minimize the impact of the "lossy" effect on a schema through conversions from a complex schema dialect, such as an XML Schema to a DTD. XA lets you use URLs to define a namespace, attribute, or join—a critical feature in the latest XML Schema specification. XA lets you open and save schema from a URL, allowing schema to be edited anywhere on the network. It also includes a plug-in API that lets you access other data repositories.

To run XA through its paces, I developed two projects. The first was to create a new schema from scratch. In the second, I grabbed one of the schema from the Rocket XML framework and refined it using the element-type and attribute-type editors built in to XA. In both cases, I exported the schema to DTD, XDR, and XSDL formats. Then I created a test XML document, and used each of the schema definitions to validate the document.

Creating a New Schema

Opening up XA and selecting "Create New Schema" brings up three windows: the hierarchy view, the element-type editor, and a small pane that indicates the parent of the current element type. The element-type editor looks like a table. Each row defines a new element type. The first column indicates the element type's name, and the second column lets you define mixed, element only, or empty content for the element type. The third column lets you create a content model, and a fourth column lets you associate attribute types with your element type.

In creating a new schema, the cursor is placed in the element-type editor and a first element is created and given the default name, "unnamed." The unnamed element type is also inserted into the tree diagram. So, the first step is to rename your element type. In this case, I'm creating a new element type called "contact" to represent each contact record in a contact-management database. When you enter the new name, the change is immediately reflected in the tree diagram.

In the second column of the element-type editor, I can select a checkbox that indicates whether the element can contain text. Because I want my contact element type to contain other element types, I've left this checkbox unselected. By selecting the Elem checkbox, I'm indicating that the contact can contain other element types. Leaving both of these checkboxes unselected indicates an empty element.

Next, I want to create the content model. When I tab over to the content model column, I'm greeted with a pair of parentheses. Within these parentheses, I can define the elements that my element type can contain, indicate sequence or choice, and include occurrence indicators. One handy feature I discovered while working with content models in the Table view is a content-model editor. Because the model can get quite long, XA lets you type Ctrl-E to bring up the content-model editor. This lets you see the entire content model and set options for each element in the model.

In any case, I want each record to contain the name, employer, address, phone number, fax, and email address for that contact. Because my data is very structured (probably coming from a database), I want these elements to occur in a sequence and want them to occur "once and only once" for each record. As with DTD syntax, I indicate this by entering the names into a comma-separated list and leaving out any occurrence indicators.

Had I wished to include occurrence indicators, a series of buttons lets me highlight individual element types referenced in the content model and apply the constraints: repeatable or optional. For example, selecting repeatable appends the + occurrence indicator, making the element required and repeatable. Selecting optional after selecting repeatable appends the * occurrence indicator, making the element optional and repeatable. Selecting optional without selecting repeatable inserts the ? occurrence indicator, meaning the element is optional, but may occur at most once within each instance.

When you're finished creating the content model you can tab over to the attributes field. Because I haven't yet created any of the element types listed in my content model, XA brings up a dialog box that gives the opportunity to auto-create these element types. Not wanting to do unnecessary typing, I selected this option. Immediately, the element type editor fills with definitions for all of the element types referenced in the content model—a nice feature!

At this point, you're left with the attributes column for the contact element. I created an attribute containing an enumerated list. This attribute's purpose is to indicate whether the contact is personal or professional. I entered my attribute's name, "type," then right-clicked on the cell. This triggered a pop-up menu from which I selected Goto Attribute Type. The attribute-type editor—another table-style editor—comes up. The columns let you modify the attribute's name and parent element type, define the attributes data type, set default attributes, determine whether the attribute is required, and set other constraints.

I wanted the type attribute to select one of two values from an enumerated list. So, I right-clicked on the Data Type column to bring up a list of data types. The list includes data types supported in XML Schema. Another sublist in this menu, called XML Types, lets me select a type for attributes. I selected Enumeration from this list. To create the enumerated list, you must tab over to the Constraints column and select the constraints button (or right click on this column). This brings up another pop-up menu from which you can select Enumeration. From there, a dialog box lets you enter the values for your list.

The last step was to create the root element type that contains our elements. So I selected Element Type from the toolbar, positioned the cursor in the last row, and created a contactDB element type, which can contain one or more contact elements. I selected Element content only, then right-clicked on the content model. This brings up a list of all of the element types that have been created. I selected Contact from this list, then made contact required and repeatable (+).

You can see the resulting schema in Figure 1. Now you can view and navigate the hierarchy of your element types using a graphical tree browser. Element types contain a content model that can be expanded and collapsed, exposing or hiding other parts of the tree. Right-clicking on an element type in the hierarchy brings up a list of options that you can use to further refine your type. Additionally, you can select Goto Element Type, which takes you to that element in the editor.

Finally, saving your schema by default saves your file as a DTD. You can change this default to save as XDR, XSDL, SOX, or any other format supported by XA. The results are shown in Listing 1. To test XA's export facility, I exported the document to XDR (see Listing 2). Then I created an XML document instance, and linked the DTD and XDR schema to this instance. Both schema worked perfectly.

Drawbacks

While I found creating schema in XA to be straightforward and intuitive, I did notice some problems. For example, the Undo/Redo feature doesn't seem to work properly. When I highlighted one of the elements in the content model and selected Optional, the UI faithfully inserted the ? character. But when I chose to undo this change, rather than removing the ?, it wiped the entire content model clean. Selecting redo reinserted the original content model, but seemed to forget the ?.

One annoyance is that upon startup, the environment seems to look for an Internet connection. In my case, this brings up my Internet Dialer every time I invoke XA. Another nagging problem is that when you click on the File menu from the Source view, the environment brings up the Open dialog box. The only way I could bring up the File menu was by entering Alt-F. Unfortunately, while this brings up the File/Save menu, it inserts the character f wherever the cursor is positioned at that time.

Also, opening and closing windows can be clumsy. Each window should include a button with an X to let you close the window. Instead, you must go to the view window or the toolbar, determine which window you want to dismiss, and select that menu or toolbar option.

One weird problem I noted is that the scrollbar doesn't always come up for the element-type editor, making it difficult to navigate to elements. I tried using the tree diagram to navigate to elements in the table view. Alas, while the cursor was placed at the proper place in the table, the position was well offscreen, and without the scrollbar, I still couldn't see the element I was attempting to edit. I also noticed that the environment doesn't catch some invalid content models. For example, I tried to set occurrence indicators for individual elements in a mixed content model. XA generated the following definition:

<!ELEMENT para1 (#PCDATA | dropCap? | bold* | ital* )*>

I didn't catch this problem until I attempted to link a document instance to the DTD.

Finally, because this tool was written using Java, the environment's reactions are extremely slow and memory intensive. This was painfully true when running XA on my older Pentium at 133 MHz with 96MB of RAM. More RAM and CPU power will give you better results.

Conclusion

XML Authority is invaluable for working with different schema types. XA lets me test my existing DTDs, and convert them to other formats in a seamless fashion. XA is also useful in exploring schema created by others. Yes, the product has a few blemishes when it comes to its user interface. However, these problems are small compared to the functionality they offer. And at the $99.95 price, I can't afford not to have XML Authority on my workbench.

(Get the source code for this article here.)

Michael is the author of Building Web Sites with XML from Prentice Hall, and architect of the Rocket XML framework. He is also the publisher of LifestylesSantaCruz.com and carries the honorary title of editor at large at Web Techniques. He can be reached at mfloyd@lifestylesSantaCruz.com.