home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

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

Bookmark It

Search this book:
 
Previous Table of Contents Next


The statement standalone=”yes” means that no markup declarations are external to the document entity. In the XML document, it is still perfectly acceptable to reference external entities (graphics files, included text, and so on), provided that the declarations of the external entities are contained inside the document entity (in other words, inside the internal DTD subset).

Standalone XML Documents

A document type declaration and the contents of an internal DTD subset are all you need to be able to define the structure of an XML document. Without any external support, without referring to any other files, an XML document containing an internal DTD subset contains enough information for it to be used for quite complex applications.

Listing 14.1 shows an XML document describing a basic catalog that uses the internal DTD subset.

Listing 14.1 Catalog.xmlStandalone XML Document with Internal DTD Subset



<?xml version=”1.0" standalone=”yes”?>
<!DOCTYPE CATALOG [
   <!ELEMENT CATALOG (PRODUCT+)>
   <!ELEMENT PRODUCT (SPECIFICATIONS+, PRICE+, NOTES?)>
   <!ATTLIST PRODUCT NAME CDATA #REQUIRED>
   <!ELEMENT SPECIFICATIONS (#PCDATA)>
   <!ATTLIST SPECIFICATIONS SIZE CDATA #REQUIRED
                            COLOR CDATA #REQUIRED>
   <!ELEMENT PRICE (#PCDATA)>
   <!ATTLIST PRICE WHOLESALE NMTOKEN #REQUIRED
             RETAIL NMTOKEN #REQUIRED
             SALES.TAX NMTOKEN #IMPLIED>
   <!ELEMENT NOTES (#PCDATA)>
]>
<CATALOG>
   <PRODUCT NAME=”T-shirt”>
      <SPECIFICATION SIZE=”XL” COLOR=”WHITE”/>
      <PRICE WHOLESALE=”9.95" RETAIL=”19.95" SALES.TAX=”2.56" SHIPPING=”5.00"/>
   </PRODUCT>
   <PRODUCT NAME=”Shirt”>
      <SPECIFICATION SIZE=”38" COLOR=”BLACK”/>
      <PRICE WHOLESALE=”69.95" RETAIL=”79.95" SALES.TAX=”4.54" SHIPPING=”10.00">
         Euro
      </PRICE>
   </PRODUCT>
</CATALOG>

Listing 14.1 starts with the now familiar XML prolog that identifies what follows as being a standalone XML version 1.0 document—one that doesn’t use an external DTD. The second line declares the document type as being a CATALOG and opens the internal DTD subset. The internal DTD subset itself follows; it describes a CATALOG element that contains one or more PRODUCT elements, a PRODUCT element containing one or more SPECIFICATION elements, followed by one or more PRICE elements, and then optional NOTES elements.

The SPECIFICATION and PRICE elements, as shown in the markup, are actually empty, and their information is included in the form of attributes. These elements could have been declared as being empty, but in this case they were not. Just because an element isn’t declared as being empty, this doesn’t stop someone from leaving the element empty. Validation can check the markup, but it actually does little or nothing to check what’s between the markup (the content), other than looking for more markup. You can have perfectly structured garbage if you wish, or even perfectly structured space and tab characters.

In this case, no currency attribute is attached to the PRICE element, so all the prices are assumed to be in the local currency. This might not always be true, so the document author has the option to add this information as text inside the PRICE element.

Note that the internal DTD subset uses elements to identify the main objects and properties of those objects; a PRODUCT has SPECIFICATION elements inside it. Most of the real property data, however, is declared as the attribute values of the SIZE, COLOR, and PRICE elements. The decision of when to use elements and when to use attributes is a difficult one to make. We will explore this problem later in this chapter. Most of the attribute values are being declared as #REQUIRED, which means that they must be given. One exception exists, though—the SALES.TAX attribute, which is #IMPLIED. This means that if the value isn’t given, the XML application running on the computer system will be able to calculate the value.

The XML document described can be validated. It contains enough of a DTD, the internal DTD subset, to enable the content and structure of the XML document to be checked. In this form, the XML document is pretty portable and good arguments exist for leaving it at that. By adding a few additional lines to the XML markup, we’ve succeeded in making the document reasonably self describing. The recipient can even perform a rough check that parts of it are complete. The fact that a complete product is missing could only be detected by the lack of a closing CATALOG tag (assuming the file was clipped in transit). You wouldn’t be able to tell through validation how many products were missing (although you could easily modify the DTD—even on-the-fly—to enable this to be checked).

Getting Sophisticated with External DTDs

So far you have already learned that you can achieve quite a lot with a standalone XML document. Although you have all the benefits of portability by keeping the DTD inside the XML document itself, you are only just touching the surface of what can be achieved when you take the next logical step and use an external DTD subset.

The fact that it’s called a document type definition already gives a clue that a DTD is intended for use with more than one XML document. Indeed, by not using an external DTD subset, you miss out on a lot of features of XML as well as the capability to use the DTD as a kind of template for a limitless set of XML documents. In XML contexts, the external DTD subset is often called an external DTD. XML has one DTD, but it’s a composite of both the internal DTD subset and the external DTD subset.

In XML, the internal DTD subset is read before the external DTD subset, and so it takes precedence. This enables you to use an external DTD subset to make global declarations and then override them on an individual basis by putting different declarations in the internal DTD subset. You’ve already learned how to associate an internal DTD subset with an XML document. The association of an external DTD subset with an XML document is rather more complicated and uses either a system identifier (system keyword) or a public identifier (public keyword) and a system identifier:

<!DOCTYPE name public.identifier system.identifier [ internal.subset ]>

Both the system identifier and the public identifier are entity identifiers.


Previous Table of Contents Next


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.