|
To access the contents, click the chapter and section titles.
Platinum Edition Using HTML 4, XML, and Java 1.2
Of course, techniques exist for mastering DTDs of this scale. You can do this by breaking the DTD into modules of a more manageable size (you will learn about this technique later in the chapter), but a point also comes where you must ask yourself whether it is really worth continuing in this way. Figure 14.9 shows a public domain software package called ez DTD that gives a kind of tabular display of the elements in the DTD. Here all you have is a list of elements, and you can display the content model for one model at a time. For simple XML applications and smaller DTDs, this kind of tool could quite possibly be as much as you will ever need, especially as you become more proficient in creating DTDs. Unfortunately, no way exists of displaying any kind of tree to show the relations between elements. Again, after the scale of the DTD increases beyond a certain point, the usefulness starts to tail off, as you can see from Figure 14.10.
It may make more sense to give up on trying to visualize the DTD altogether, although a recommended tool is Earl Hoods public domain Perl script, DTD2HTML. This package converts a DTD into a set of interlinked HTML pages. The output isnt a great deal of help while youre actually developing the DTD, but it is extremely useful for checking the results of your work and is excellent as a means of documenting the completed DTD. Instead of visually modeling the DTD, you may ultimately find it easier to learn to use a more conservative package, such as Innovation Partners DTD Generator package, shown in Figure 14.11. In this no-frills package, you have a halfway point between the two camps. In this package, you have all the ease of dedicated buttons that enable you to add the parts of content models quickly, but there is no attempt to give any kind of visual display. Instead, you can very quickly flip backward between the ease-of-use interface and the raw DTD code.
XML DTDs from Other SourcesOne alternative to getting involved in the complexities of DTD design and development is to leave the DTD design to one side and work on a representative XML document. You must, of course, ensure that you consider all the likely variations of the document, and you will probably need several documents as your XML application becomes larger. However, after you have explored all the possibilities in the XML document, you can then use tools to create at least the core of the DTD for you. Although this would be almost impossible for an SGML application, this approach will often be a realistic choice for XML applications. As you can see from the real-life document loaded in XMLPro in Figure 14.12, a good XML editor will enable you to browse through the structure of the document, adding elements and attributes wherever you need them. Although you may find yourself repeating some steps unnecessarily, it is easy enough to consolidate the multiple declarations afterward. One significant benefit is gained from this approach that no specialized DTD tool can give you. By exposing you to what amounts to being a completed XML document using your (proposed) DTD, you get a first-hand taste of what it would be like for a human author to work with your DTD. Many of the mainstream software packages, such as Adobes FrameMaker and even Microsofts Office suite, will be supporting XML as an output format in the near future. This opens up all sorts of possibilities for getting the structure of an intended XML correct in one of those software packages and then either creating the DTD from that document, or even skipping the DTD altogether. An interesting development in this direction is the Majix software package from Tetrasix. This software package, shown in Figure 14.13, enables you to create an XML document from a Microsoft RTF format document. If you use Microsoft Word, for example, and you use Word styles properly, you can use these styles to drive the conversion into XML elements.
Modeling Relational DatabasesIn this discussion of developing DTDs, the elements have consistently been structured hierarchically. Generally, this really is what you need to do, but instances might occur where you might want toor even need toavoid having too much of a hierarchy, and you want to keep the model flat. Such an application would be when you are using XML to model a relational database, an application that XML is ideally suited for (subject to the planned XML data typing initiatives bearing fruit). Consider the simple relational database description shown in Listing 14.5. Although the topic of database modeling in XML deserves more extensive treatment than can be given here, even a quick appraisal shows that you dont really need that much depth. The simple database shown here, in fact, only needs four levels:
After you have this structure, its a simple matter to add table and record keys by assigning attributes. In this way, you could create a forced division between using the elements to describe the content and structure of the database itself and reserve the use of attributes for the (internal) data that describes the relations between the data. Listing 14.5 Music.xmlXML Description of a Music Database <?xml version=1.0"?> <!DOCTYPE music SYSTEM mymusic.dtd> <music> <artists> <artist> <name>Cyndi Lauper</name> <label>Sony</label> <title>Twelve Deadly Guns</title> </artist> <artist> <name>Kate Bush</name> <label>EMI</label> <title>Hounds of Love</title> </artist> </artists> <discs> <disc> <title>Twelve Deadly Guns</title> <date>1994</date> <number>EPC 477363 2</number> </disc> <disc> <title>Hounds Of Love</title> <date>1985</date> <number>CDP 7 46164 2</number> </disc> </discs> </music>
|
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement. |