Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

Structure the Elements

Having identified and named the elements in your XML document, the next step is to arrange the elements into some kind of hierarchical (tree) arrangement. The complexity of the tree that you make will largely depend on your application. If you are modeling a database, then you might want to keep the hierarchy fairly flat, but at the very least you must obey the rules of being well formed and having only one root element that contains all the other elements. You will probably find that a pencil-and-paper sketch of the structure will be a great help.

While structuring, look for group and container elements. Group elements are things such as lists, definition lists, and glossaries that arrange sets of elements as units. Sometimes you will need to consciously create extra elements to collect other elements to make processing easier. A container list for a set of numbered paragraphs, for instance, makes it easier to number the paragraphs and reset the number each time you start a new set. A useful clue to the need for a container element is that if you find yourself thinking of a set, a list, or a group of elements, you should automatically start thinking container.

Examples of container elements are the HEAD and BODY elements in HTML, or perhaps separate MESSAGE.HEADER and MESSAGE.TEXT elements for an email message DTD. A rough, general rule for containers is to look at the content model for the element. If you cannot easily understand what it means without having to stop and think, it is too complex, and you should consider breaking it up with a container element.

Enforce the Rules

So far, you should have been concentrating on getting everything identified and organized. Only when these stages have been completed should you start to think about enforcing your model, making elements optional and required. Think carefully about how strict you want to be and how much validation you need. If your XML code is to be computer generated, perhaps from a database, there probably isn’t much point in wasting time and energy in tightening up the DTD. After all, you then have complete control over the generation of the XML markup. On the other hand, if the XML markup is to be created by humans, you will probably want to make sure that certain elements are not forgotten.

When you make elements optional, be careful that you don’t make the content model ambiguous. Remember that XML parsers are not very complex and are unable to look ahead at what comes next in the XML document. At each point in the content model, it must be absolutely clear what element is allowed next. Sometimes you will have to use some clever tricks to get around these ambiguities.

Assigning Attributes

Only after you have arranged your elements into a hierarchical structure and grouped them as necessary should you assign attributes to them (size, color, ID and so on). At this point, you may find that you will want to move some of the information into attributes, which is why it helps to keep the two tasks separate.

No real rules exist about when to use attributes and when to use elements, although there is still a lot of discussion about it. This issue will be discussed in greater depth later in this chapter, but you can usually use common sense as a guide. One good way to divide them up is that things that are nouns should be elements, and things that are adjectives or adverbs should be attributes. So, in our Catalog example from Listing 14.1, the products themselves are elements, but the characteristics of those products, such as price and color, are attributes.

Tool Assistance

A number of quite good XML editors are already available. Although some of them are still in early stages of development and it is still unclear what features are actually required by users, a trend is apparent. In less than a year, along a path that very roughly parallels that followed by HTML tools, we have moved from markup-aware text editors to a kind of word processor package attuned to editing XML code. The XML editors that are now appearing on the market are beginning to add dedicated XML capabilities such as validation.

A Home Page DTD

Listing 14.2 shows an example of a simple XML document used to show a sample home page. In this section, I will build on this example to demonstrate how to put together a simple DTD.

Listing 14.2 Home.xml—Home Page XML Document

<?xml version=”1.0"?>
<home.page>
   <head>
      <title>
         My Home Page
      </title>
      <banner source=”topbanner.gif”/>
   </head>
   <body>
      <main.title>
         Welcome to My Home Page
      </main.title>
      <rule/>
      <text>
         <para>
            Sorry, this home page is still under construction.
            Please come back soon!
         </para>
      </text>
   </body>
   <footer source=”foot.gif”/>
</home.page>

By pulling this document into an XML tool such as the XMLPro Editor, which can be found on the Web at http://www.vervet.com/, without a DTD (see Figure 14.3), you can then add elements, delete them, and move them around. After you’ve finished and are satisfied with the results, you can use the tree structure shown in the left window to see the way you have structured things. You can easily explore your tree, expanding and collapsing branches. The tree structure you will see gives you a good head start on describing the structure you want in your DTD.

If you pull the same XML markup into a different application, STILO WebWriter, it isn’t quite as easy to navigate the structure as in XMLPro, but WebWriter compensates by enabling you to actually generate the DTD (see Figure 14.4).

Listing 14.3 shows the extracted DTD (slightly edited to enhance readability) derived from the sample XML document home page.

FIGURE 14.3  Exploring the structure in XMLPro Editor.

FIGURE 14.4  Creating the DTD in STILO WebWriter.

Listing 14.3 Home_WW.dtd—DTD Generated from Home.xml

<?xml version = “1.0”?>
<!ELEMENT home.page (#PCDATA | head | body | footer)*>
<!ELEMENT head (#PCDATA | title | banner)*>
<!ELEMENT title (#PCDATA)>
<!ELEMENT banner EMPTY>
<!ATTLIST banner source CDATA “”>
<!ELEMENT body (#PCDATA | main.title | rule | text)*>
<!ELEMENT main.title (#PCDATA)>
<!ELEMENT rule EMPTY>
<!ELEMENT text (#PCDATA | para)*>
<!ELEMENT para (#PCDATA)>
<!ELEMENT footer EMPTY>
<!ATTLIST footer source CDATA “”>
<!ENTITY lt “<“>
<!ENTITY gt “>”>
<!ENTITY apos “‘“>
<!ENTITY quot “””>
<!ENTITY amp “&”>