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

Even in the absence of a DTD, an XML parser should correctly parse a well-formed document. This means that the parser can build the document tree (the logical structure that the parser creates as it processes the document), but it cannot assess the proper use of the elements.

The key thing to remember about well-formed documents is this: If it is not well formed, it is not XML. A document that is not well formed will be summarily rejected by any XML parser. This seemingly rigid approach has two important advantages:

•  It ensures that XML never “breaks” a browser the way extended HTML tags can. If a document is well formed, an XML browser is guaranteed to be capable of rendering it. If a document isn’t well formed, the browser just ignores it.

•  It forces XML authors to get into good coding habits, as opposed to the sloppy habits that have come to plague HTML documents. Because the rules of being well-formed are well established, any XML editing program should be capable of checking an author’s work to determine whether it is well formed before saving.

If a DTD is specified for a well-formed document and the document conforms to the DTD, the document is said to be valid. Validity is a stronger requirement than being well-formed. However, because validity implies the presence of a DTD, it is certainly the preferred state of the two. The primary benefit of having a valid document is that it is widely publishable. A valid document has to have a DTD, and if you make that DTD available with the document, any XML processing program can use the DTD to facilitate the parsing and rendering of the document. Because the DTD formally defines the document, it also becomes easier to bring other functionality to bear on the document, such as search engines, style sheets, nonvisual browsers, and printing applications.

Linking with XML

The first phase of the W3C’s rollout of XML was issuing the recommendation for basic XML grammar. That recommendation is really just a set of rules for how elements, entities, processing instructions, and so on must be structured for a document to be considered an XML document. The draft does not specify any particular elements because XML authors are free to create their own. The same is true for entities, except for the five reserved entity characters (<, >, &, ", '). Although the draft may seem vague, remember that, in a sense, it is supposed to be. The “extensibility” part of XML comes from the capability to form your own sets of elements and entities according to your needs.

One important idea that the recommendation does not address is that of linking documents. If you are familiar with HTML, you know that you use an <A> element with the HREF attribute to link text or graphics to another document. But because no specific elements exist in XML, you may be wondering how XML documents get linked together. The answer lies in the second phase of the XML rollout—the draft proposal for XML linking using the XML Linking Language (XLink) and the XML Pointer Language (XPointer). In keeping with the “extensible and flexible” philosophy inherent in XML, XLink and XPointer call for more than the traditional, unidirectional linking you get with HTML. Instead, you can do extended linking that allows for multidirectional links or links to special kinds of information. The next few sections look at what is possible in linking XML documents.

---

NOTE:  The XLink proposal is constantly evolving, so be sure to check the W3C site at http://www.w3.org/TR/WD-xlink for the most recent changes to the proposal.

---

XLink

The W3C published a proposed XLink 1.0 standard in March 1998. That proposal put forth the notion of two classes of links:

•  Simple links—Simple links are one-directional links from one resource to another, similar to how you use the <A> element in HTML. Simple links are usually inline, which means that the content of the element describing the link serves as a resource of the link. The <A> element, for example, produces inline links because its contents (the HREF attribute) specify the link’s resource (the document the link points to).

•  Extended links—Extended links are links that can be multidirectional. Additionally, you can use the notion of extended links to define what is known as an extended link group (described later in the chapter).

You are free to make up whatever element you like to specify an XML link, but that link must contain the XML:LINK attribute, which is reserved so that parsers and browsers have some way of knowing that the element is defining a link. To create links, you usually set XML:LINK to one of two values: SIMPLE or EXTENDED. You can also use other values of XML:LINK when defining extended links. The next two sections review the specifics of each type of link.

Simple Links The simple XML link is very much like the link you get with the <A> element in HTML. Because it is up to the XML author as to what to name an element, no specific element name is reserved for use when linking. For the purposes of this section, the simple linking element is <SIMPLINK>. You are welcome to call the simple link element whatever you would like in your own documents.

What sets simple linking apart from basic linking in HTML is the much greater number of attributes that a simple link element can take. Table 11.1 summarizes these attributes.