XML

The Extensible Markup Language (XML) does for HTML what distributed objects do for HTTP. XML is the creation of the W3C, which also controls the evolution of HTML. XML offers Web application developers another way to express Web page content. One of the principal problems with HTML is that content and presentation details are woven into the same document. XML documents don't contain presentation information; instead, a separate document, formatted with the Extensible Stylesheet Language (XSL) or a cascading style sheet (CSS) document, is referenced in order to render the document in a browser. In most situations, XML documents are not rendered only in browsers but are used as a cross-platform way to managing and communicate data between systems.

A lot of hype surrounds XML, as well as a lot of confusion as to what XML is and how it relates to Web applications. It is true that XML is powerful and will be a significant player in the next generations; however, it is not a technological silver bullet. XML is just a language, or rather a metalanguage. To be effective, therefore, it requires agreement by all parties using it. Additionally, XML is not dependent on Web architectures; nor are Web architectures dependent on XML. Although their evolution has been tightly related, they are separate technologies and concepts.

Basically, an XML-formatted document is a text document that defines a hierarchical collection of elements. An element is one part of a document and usually contains a textual value. An element can have child elements and thus form a hierarchy. Every XML document begins with one root element. Elements can be enhanced with attributes, which are just key/value pairs. Elements have bodies that can contain free-form text, with some restrictions.

The beauty of XML, and the reason that so many people are interested in it, is that you can define your own element types and associate your own semantics with it. In effect, XML offers the basic rules for formatting generic documents so that simple parsers can read and validate their contents. With the availability of free parsers, development teams are more likely to adopt XML document structures as a standard.

Most content of an XML document is textual; however, elements of the document can point to, but not directly contain, nontextual resources, such as images or applications.[2] By describing documents with XML, generic XML parsers can be used to extract the document's structure. Individual applications will still have to apply semantic meanings to the elements. A document that obeys XML formatting rules is considered well formed and can be parsed by any generic XML parser.

[2] Of course, a binary file can be encoded into normal text, but this is beyond the scope of XML. In the majority of situations, XML documents contain references to binary data only through URLs or relative file system paths.

XML, like HTML, has its roots in the Standard Generalized Markup Language (SGML), the mother tongue for a whole group of document-formatting languages. XML formats its content with tags. An XML element is expressed with a pair of tags: a beginning tag and an ending tag. The following XML document could be used to express a postal address:

123 Pine Rd. Lexington SC 19072

A proper XML document begins with a heading that indicates the version of XML and the encoding character set. As in HTML, tags are surrounded by angle brackets (< >). White space outside of tags is optional, so the indenting of the address's child elements is strictly for human reading. Space between an element's tags is not ignored, however. Ending tags are denoted by a slash as the first character, followed by the tag name. The text between these tags is the element's value. An element's value can be any combination of text or child elements. In the preceding example, the

element has four child elements, each of which contains textual information.

Unlike HTML, elements cannot have open-ended or overlapping tags. Every beginning tag must have an ending tag, or the tag can be constructed in a shorthand form:

The tag for pobox is both a beginning and an ending tag. This tag on its own conveys no information, except its existence. Additional information can be tied to an element through the use of element attributes. For example, the tag pobox might have the attributes id and rural defined:

When these attributes are included, the usefulness of the pobox tag becomes clearer.

The trick to successfully using XML in an application and across applications is in obtaining agreement on the structure and the semantics of the documents that will be used. The preceding address element is intuitive to a human being, at least to U.S. residents, but an automated application must be programmed to accept address information in this form. Take as an example a healthcare provider that has an application that exchanges patient information with an insurance company. The insurance company might expect address information in the preceding form, but the healthcare company might supply addresses in the following form:

123 Pine Rd.

The insurance company application will not automatically associate the proper semantic meaning to the document and will not be able to use it. In order for XML to be used as a general data interchange medium, a mechanism is needed to help coordinate and to define the construction. The answer lies in a DTD.

A document type definition (DTD) is a document that defines the syntax for a particular type of XML document. DTDs are used to determine whether any given XML document is valid; that is, its structure is defined by a DTD. A DTD is a document that can be embedded in an XML document or exist as a file on the network and be referenced in the document. DTD syntax rules are a little different from those of XML.

A DTD is not required for a parser to read the document. Our first XML address document example is a well-formed document that can be read and parsed; however, it is unclear whether it is also a valid document. For this, it must be checked against a DTD. If the DTD was included with the first version of the address, the XML document would be as follows:

]>

123 Pine Rd. Lexington SC 19072

The DTD, beginning with the keyword !DOCTYPE, specifies five element types. The root elementand name of the document typeis specified to contain four child element types. All the child elements contain only parsed character data (#PCDATA). Parsed character data is text that does not contain special markup characters, such as <, >, and &. This XML document, with embedded DTD, can be validated with a validating XML parser.

Instead of embedding a DTD in every XML document, it is possible to reference it and give the parser the option of fetching it use a cached copyto perform the validation. The second address XML document could be constructed with a referenced DTD as follows:

123 Pine Rd. Apt B116

In this document, the DTD can be obtained with the URL specified after the SYSTEM keyword. This particular URL happens to specify also the machine name and protocol that can be used to obtain the document.

As XML becomes more popular and standards become defined, there is a greater chance that element names might collide. Because anyone can create elements, it is possible that a banking application, for example, might define the element to mean the state of the accountopen, closed, pending, and so on. Another application, dealing with psychological things, might define state to mean "normal," "depressed," "schizophrenic," and so on. While these elements remain in their own documents, there is not much of a problem. But a problem does arise for the designer of the Mental Health Home Banking application. The situation might be contrived, but it does illustrate the possibility of instances in which multiple XML documents get packaged together and name collisions occur. The element could now have three meanings: part of an address, account status, or mental condition. This reuse of the element would be very confusing for a validating parser.

To help parsers resolve this dilemma, the W3C has recently defined a namespace mechanism. In an XML document, a namespace can be defined that will allow us to continue to use the element name of , but in each instance, we can define the namespace it belongs in. Each namespace is identified with the special attribute xmlns and requires a unique identifier, which is usually a common URL. For example, our address element might define a default namespace for the document:

123 Pine Rd. Lexington SC 19072

In this example, a default namespace is defined for all elements of the address: the root element.

Namespaces can be qualified and multiple namespaces used in a single document. For example, our banking application might use a document like the following:

jim conallen 123456789 normal 123 Pine Rd. Lexington SC 19072

In this example, three namespaces are defined, with one as the default. When referencing an element that is not part of the default namespace, the element name is prefixed with the namespace. With the namespaces defined, a validating parser has a much better chance of understanding and validating the document against a DTD.

Although DTDs are useful in Web applications, they have shortcomings.

• DTDs don't allow the specification of data types, such as numbers or dates.
• DTDs cannot be reused or combined to form new document definitions.
• The grammar of a DTD is different from that of XML and can be difficult to understand, especially by new users.
• It is not easy to expand the DTD with new features.

The next step for describing XML document structures is XML schemas. XML schemas were introduced by Microsoft but are now under the management of the W3C. An XML schema, like a DTD, describes the structure of an XML document and also happens to be a valid XML document in its own right. In addition to describing a valid XML document, an XML schema can go further to define element data types.

The XML schema that describes the second version of the postal address might look like the following:

Comment describing the element

The details of the syntax are beyond the scope of this book; however, it is important to note that this entire schema is itself a valid XML document. The same parser that parses XML documents can be used to parse the schema document. In this document, data types are specified for some of the elements. There is also a place to include element descriptions, which can be captured by the parser. (Comments in DTDs are often skipped over by parsers and don't have obvious connections to the elements they describe.)

The use of XML in an application can get very complex. Just as this book advocates the modeling of Web applications with UML to help understand Web-centric architectures, it is possible to model XML with UML.[3]

[3] See David Carlson, Modeling XML Applications with UML: Practical e-Business Applications (Boston, MA: Addison-Wesley, 2001).