This is chapter one from the book, XML and FrameMaker, by Kay Ethier (Apress, ISBN: 159059276X. 2004). Ethier reviews some of the basic XML terms and rules, and provides a basic overview of the purpose of DTDs and XSLT.
Introduction to XML - Understanding XML Rules (6-7) (Page 6 of 7 )
Rule 6: Attribute values must always be quoted.
Attributes in XML documents must be properly quoted. This is also a rule for HTML documents, although browsers have been designed to be forgiving on this point. HTML documents that have unquoted attributes will usually still display. XML documents with unquoted attributes are not well-formed. Remember to quote your attribute values. For example,
<figure source="doe02.svg" />
NOTE: Attributes must consist of a name-and-value pair, such as draft="final".
Rule 7: All entities and special characters must be used properly.
Special characters must be defined and used properly. An ampersand (&), for example, cannot be typed directly into your content. It must be set up as an entity.
Beyond these simple rules, you have a lot of free reign as to what elements your XML documents can contain. Quite honestly, if you don't have a specific purpose or method in mind, it will not matter what you include in your XML.
Looking at XML with Quality Checking
At this point, it probably looks like XML is easy. Well, it is and it isn't. You can follow the preceding rules and make up the tags as you go, but that will not do much for you. If you really get into reusing your information and making good use of XML, you will want to specify a list of the elements and how they can be used.
This becomes imperative as you move forward and begin formatting, reusing, and sharing your XML. Tools-and people-need to know what elements and structure to expect.
In our accounting example (see page 11), there are many tags that make up an invoice. These include <inv_num>, <client>, <amount>, <due_date>, and many others.
In an ideal situation, you would have a list of all these elements and how they can be used. This list would then be put into a format that allows a machine or a software package to check the XML for you (eliminating errors by human editors). Such a list is called a DTD.
As mentioned in the terminology section, the DTD lists the elements and a rule about how the element can be used. The process of checking your XML documents against the rules to check compliance is called validation (also mentioned in the terminology section). Documents that follow the DTD content rules are valid. Documents which do not follow the rules of a DTD, but follow the rules of XML, are well-formed.
For example, you can define the tag
<invoice> and state in its rule that it always has to have <client>, <amount>, and <due_date>, but doesn't always have to have an <inv_num>. You can then use a software package that checks the XML against the DTD and validates it to make sure that all the invoices have the appropriate information.
Some software can even show you where there are missing pieces so the XML can be fixed. You'll see this in FrameMaker, which displays missing pieces as red symbols in a Structure View.
Note: Valid documents are always well-formed, but well-formed documents are not necessarily valid.
This chapter is from XML and Framemaker, by Kay Ethier (Apress, 2004, ISBN: 159059276X). Check it out at your favorite bookstore today.