This tutorial covers the basics of XML. The goal is to give you just enough information to get started, so you understand what XML is all about. (You'll learn about XML in later sections of the tutorial.) We then outline the major features that make XML great for information storage and interchange, and give you a general idea of how XML can be used.
XML is a text-based markup language that is fast becoming the
standard for data interchange on the Web. As with HTML, you identify data using
tags (identifiers enclosed in angle brackets, like this:
<...>). Collectively, the tags are known as "markup".
But unlike HTML, XML tags
identify the data, rather than specifying how to display it. Where an
HTML tag says something like "display this data in bold font" (<b>...</b>),
an XML tag acts like a field name in your program. It puts a label on a piece of
data that identifies it (for example:
<message>...</message>).
Note: Since identifying the data gives you some sense of what means (how to interpret it, what you should do with it), XML is sometimes described as a mechanism for specifying the semantics (meaning) of the data.
In the same way that you define the field names for a data structure, you are free to use any XML tags that make sense for a given application. Naturally, though, for multiple applications to use the same XML data, they have to agree on the tag names they intend to use.
Here is an example of some XML data you might use for a messaging application:
<message> <to>you@yourAddress.com</to> <from>me@myAddress.com</from> <subject>XML Is Really Cool</subject> <text> How many ways is XML cool? Let me count the ways... </text> </message>
Note: Throughout this tutorial, we use boldface text to highlight things we want to bring to your attention. XML does not require anything to be in bold!
The tags in this example identify the message as a whole, the
destination and sender addresses, the subject, and the text of the message. As
in HTML, the <to> tag has a matching end tag:
</to>. The data between the tag and its matching end
tag defines an element of the XML data. Note, too, that the content of the
<to> tag is entirely contained within the scope of
the <message>..</message> tag. It is this ability for
one tag to contain others that gives XML its ability to represent hierarchical
data structures.
Once again, as with HTML, whitespace is essentially irrelevant, so you can format the data for readability and yet still process it easily with a program. Unlike HTML, however, in XML you could easily search a data set for messages containing "cool" in the subject, because the XML tags identify the content of the data, rather than specifying its representation.
Tags can also contain attributes--additional information
included as part of the tag itself, within the tag's angle brackets. The
following example shows an email message structure that uses attributes for the
"to",
"from", and
"subject" fields:
<message to="you@yourAddress.com" from="me@myAddress.com" subject="XML Is Really Cool"> <text> How many ways is XML cool? Let me count the ways... </text> </message>
As in HTML, the attribute name is followed by an equal sign and the attribute value, and multiple attributes are separated by spaces. Unlike HTML, however, in XML commas between attributes are not ignored--if present, they generate an error.
Since you could design a data structure like
<message> equally well using either attributes or
tags, it can take a considerable amount of thought to figure out which design is
best for your purposes.
One really big difference between XML and HTML is that an XML
document is always constrained to be well formed. There are several rules that
determine when a document is well-formed, but one of the most important is that
every tag has a closing tag. So, in XML, the
</to>
tag is not optional. The <to> element is never
terminated by any tag other than
</to>.
Note: Another important aspect of a well-formed document is
that all tags are completely nested. So you can have
<message>..<to>..</to>..</message>, but never
<message>..<to>..</message>..</to>. A complete list of requirements is
contained in the list of XML Frequently Asked Questions (FAQ) at
http://www.ucc.ie/xml/#FAQ-VALIDWF. (This FAQ is on the w3c
"Recommended Reading" list at
http://www.w3.org/XML/.)
Sometimes, though, it makes sense to have a tag that stands by
itself. For example, you might want to add a
"flag"
tag that marks message as important. A tag like that doesn't enclose any
content, so it's known as an "empty tag". You can create an empty tag by ending
it with /> instead of
>.
For example, the following message contains such a tag:
<message to="you@yourAddress.com" from="me@myAddress.com" subject="XML Is Really Cool"> <flag/> <text> How many ways is XML cool? Let me count the ways... </text> </message>
Note: The empty tag saves you from having to code
<flag></flag> in order to have a well-formed
document. You can control which tags are allowed to be empty by creating a
Document Type Definition, or DTD.
We'll talk about that in a few moments. If there is no DTD, then the document
can contain any kinds of tags you want, as long as the document is well-formed.
XML comments look just like HTML comments:
<message to="you@yourAddress.com" from="me@myAddress.com" subject="XML Is Really Cool"> <!-- This is a comment --> <text> How many ways is XML cool? Let me count the ways... </text> </message>
To complete this journeyman's introduction to XML, note that an XML file always starts with a prolog. The minimal prolog contains a declaration that identifies the document as an XML document, like this:
The declaration may also contain additional information, like this:
The XML declaration is essentially the same as the HTML header,
<html>, except that it uses
<?..?> and it may contain the following attributes:
version
Identifies the version of the XML markup language used in the data. This attribute is not optional.
encoding
Identifies the character set used to encode the data. "ISO-8859-1" is "Latin-1" the Western European and English language character set. (The default is compressed Unicode: UTF-8.)
standalone
Tells whether or not this document references an external entity or an external data type specification (see below). If there are no external references, then "yes" is appropriate
The prolog can also contain definitions of entities (items that
are inserted when you reference them from within the document) and
specifications that tell which tags are valid in the document, both declared in
a Document Type Definition (DTD)
that can be defined directly within the prolog, as well as with pointers to
external specification files. But those are the subject of later tutorials. For
more information on these and many other aspects of XML, see the Recommended
Reading list of the w3c XML page at
http://www.w3.org/XML/.
Note: The declaration is actually optional. But it's a good idea to include it whenever you create an XML file. The declaration should have the version number, at a minimum, and ideally the encoding as well. That standard simplifies things if the XML standard is extended in the future, and if the data ever needs to be localized for different geographical regions.
Everything that comes after the XML prolog constitutes the document's content.
An XML file can also contain processing instructions that give commands or information to an application that is processing the XML data. Processing instructions have the following format:
where the target is the name of the application that is expected to do the processing, and instructions is a string of characters that embodies the information or commands for the application to process.
Since the instructions are application specific, an XML file could have multiple processing instructions that tell different applications to do similar things, though in different ways. The XML file for a slideshow, for example, could have processing instructions that let the speaker specify a technical or executive-level version of the presentation. If multiple presentation programs were used, the program might need multiple versions of the processing instructions (although it would be nicer if such applications recognized standard instructions).
Note: The target name "xml" (in any combination of upper or lowercase letters) is reserved for XML standards. In one sense, the declaration is a processing instruction that fits that standard. (However, when you're working with the parser later, you'll see that the method for handling processing instructions never sees the declaration.)
There are a number of reasons for XML's surging acceptance. This section lists a few of the most prominent.
Since XML is not a binary format, you can create and edit files with anything from a standard text editor to a visual development environment. That makes it easy to debug your programs, and makes it useful for storing small amounts of data. At the other end of the spectrum, an XML front end to a database makes it possible to efficiently store large amounts of XML data as well. So XML provides scalability for anything from small configuration files to a company-wide data repository.
XML tells you what kind of data you have, not how to display it. Because the markup tags identify the information and break up the data into parts, an email program can process it, a search program can look for messages sent to particular people, and an address book can extract the address information from the rest of the message. In short, because the different parts of the information have been identified, they can be used in different ways by different applications.
When display is important, the stylesheet standard, XSL, lets you dictate how to portray the data. For example, the stylesheet for:
can say:
Which produces:
Of course, you could have done the same thing in HTML, but you wouldn't be able to process the data with search programs and address-extraction programs and the like. More importantly, since XML is inherently style-free, you can use a completely different stylesheet to produce output in postscript, TEX, PDF, or some new format that hasn't even been invented yet. That flexibility amounts to what one author described as "future-proofing" your information. The XML documents you author today can be used in future document-delivery systems that haven't even been imagined yet.
One of the nicer aspects of XML documents is that they can be composed from separate entities. You can do that with HTML, but only by linking to other documents. Unlike HTML, XML entities can be included "in line" in a document. The included sections look like a normal part of the document--you can search the whole document at one time or download it in one piece. That lets you modularize your documents without resorting to links. You can single-source a section so that an edit to it is reflected everywhere the section is used, and yet a document composed from such pieces looks for all the world like a one-piece document.
Thanks to HTML, the ability to define links between documents is now regarded as a necessity.
As mentioned earlier, regular and consistent notation makes it
easier to build a program to process XML data. For example, in HTML a
<dt> tag can be delimited by
</dt>,
another <dt>,
<dd>, or
</dl>. That makes for some difficult programming. But
in XML, the <dt> tag must always have a
</dt> terminator, or else it will be defined as a
<dt/> tag. That restriction is a critical part of the
constraints that make an XML document well-formed. (Otherwise, the XML parser
won't be able to read the data.) And since XML is a vendor-neutral standard, you
can choose among several XML parsers, any one of which takes the work out of
processing XML data.
Finally, XML documents benefit from their hierarchical structure. Hierarchical document structures are, in general, faster to access because you can drill down to the part you need, like stepping through a table of contents. They are also easier to rearrange, because each piece is delimited. In a document, for example, you could move a heading to a new location and drag everything under it along with the heading, instead of having to page down to make a selection, cut, and then paste the selection into a new location.
There are several basic ways to make use of XML:
XML is fast becoming the data representation of choice for the Web. It's terrific when used in conjunction with network-centric Java-platform programs that send and retrieve information. So a client/server application, for example, could transmit XML-encoded data back and forth between the client and the server.
In the future, XML is potentially the answer for data
interchange in all sorts of transactions, as long as both sides agree on the
markup to use. (For example, should an e-mail program expect to see tags named
<FIRST> and
<LAST>, or
<FIRSTNAME> and
<LASTNAME>)
The need for common standards will generate a lot of industry-specific
standardization efforts in the years ahead. In the meantime, mechanisms that let
you "translate" the tags in an XML document will be important. Such mechanisms
include projects like the RDF
initiative, which defines "meta tags", and the XSL
specification, which lets you translate XML tags into other XML tags.
The newest approach to using XML is to construct a document that describes how an application page should look. The document, rather than simply being displayed, consists of references to user interface components and business-logic components that are "hooked together" to create an application on the fly.
Of course, it makes sense to utilize the Java platform for such components. Both Java Beans components for interfaces and Enterprise Java Beans components for business logic can be used to construct such applications. Although none of the efforts undertaken so far are ready for commercial use, much preliminary work has already been done.
Note: The Java programming language is also excellent for
writing XML-processing tools that are as portable as XML. Several Visual XML
editors have been written for the Java platform. For a listing of editors,
processing tools, and other XML resources, see the "Software" section of Robin
Cover's SGML/XML Web Page at
http://www.oasis-open.org/cover/.
Once you have defined the structure of XML data using either a
DTD or the one of the schema standards, a large part of the processing you need
to do has already been defined. For example, if the schema says that the text
data in a <date> element must follow one of the
recognized date formats, then one aspect of the validation criteria for the data
has been defined--it only remains to write the code. Although a DTD
specification cannot go the same level of detail, a DTD (like a schema) provides
a grammar that tells which data structures can occur, in what sequences. That
specification tells you how to write the high-level code that processes the data
elements.
But when the data structure (and possibly format) is fully specified, the code you need to process it can just as easily be generated automatically. That process is known as binding--creating classes that recognize and process different data elements by processing the specification that defines those elements. As time goes on, you should find that you are using the data specification to generate significant chunks of code, so you can focus on the programming that is unique to your application.
The Holy Grail of programming is the construction of reusable, modular components. Ideally, you'd like to take them off the shelf, customize them, and plug them together to construct an application, with a bare minimum of additional coding and additional compilation.
The basic mechanism for saving information is called archiving. You archive a component by writing it to an output stream in a form that you can reuse later. You can then read it in and instantiate it using its saved parameters. (For example, if you saved a table component, its parameters might be the number of rows and columns to display.) Archived components can also be shuffled around the Web and used in a variety of ways.
When components are archived in binary form, however, there are some limitations on the kinds of changes you can make to the underlying classes if you want to retain compatibility with previously saved versions. If you could modify the archived version to reflect the change, that would solve the problem. But that's hard to do with a binary object. Such considerations have prompted a number of investigations into using XML for archiving. But if an object's state were archived in text form using XML, then anything and everything in it could be changed as easily as you can say, "search and replace".
XML's text-based format could also make it easier to transfer objects between applications written in different languages. For all of these reasons, XML-based archiving is likely to become an important force in the not-too-distant future.
Now that you have a basic understanding of XML, it makes sense to get a high-level overview of the various XML-related acronyms and what they mean. There is a lot of work going on around XML, so there is a lot to learn.
The current APIs for accessing XML documents either serially or in random access mode are, respectively, SAX and DOM. The specifications for ensuring the validity of XML documents are DTD (the original mechanism, defined as part of the XML specification) and various Schema Standards proposals (newer mechanisms that use XML syntax to do the job of describing validation criteria).
Other future standards that are nearing completion include the XSL standard--a mechanism for setting up translations of XML documents (for example to HTML or other XML) and for dictating how the document is rendered. The transformation part of that standard, XSLT (+XPATH), is completed and covered in this tutorial. Another effort nearing completion is the XML Link Language specification (XML Linking), which enables links between XML documents.
Those are the major initiatives you will want to be familiar with. This section also surveys a number of other interesting proposals, including the HTML-lookalike standard, XHTML, and the meta-standard for describing the information an XML document contains, RDF. There are also standards efforts that extend XML's capabilities, such as XLink and XPointer.
Finally, there are a number of interesting standards and standards-proposals that build on XML, including Synchronized Multimedia Integration Language , Mathematical Markup Language , Scalable Vector Graphics and DrawML, as well as a number of eCommerce standards.
The remainder of this section gives you a more detailed description of these initiatives. To help keep things straight, it's divided into:
Skim the terms once, so you know what's here, and keep a copy of this document handy so you can refer to it whenever you see one of these terms in something you're reading. Pretty soon, you'll have them all committed to memory, and you'll be at least "conversant" with XML!
These are the basic standards you need to be familiar with. They come up in pretty much any discussion of XML.
Simple API for XML
This API was actually a product of collaboration on the XML-DEV mailing list, rather than a product of the W3C. It's included here because it has the same "final" characteristics as a W3C recommendation.
You can also think of this standard as the "serial access" protocol for XML. This is the fast-to-execute mechanism you would use to read and write XML data in a server, for example. This is also called an event-driven protocol, because the technique is to register your handler with a SAX parser, after which the parser invokes your callback methods whenever it sees a new XML tag (or encounters an error, or wants to tell you anything else).
Document Object Model
The Document Object Model protocol converts an XML document into a collection of objects in your program. You can then manipulate the object model in any way that makes sense. This mechanism is also known as the "random access" protocol, because you can visit any part of the data at any time. You can then modify the data, remove it, or insert new data.
While the Document Object Model (DOM) provides a lot of power for document-oriented processing, it doesn't provide much in the way of object-oriented simplification. Java developers who are processing more data-oriented structures--rather than books, articles, and other full-fledged documents--frequently find that object-oriented APIs like JDOM and dom4j are easier to use and more suited to their needs.
Here are the important differences to understand when choosing between the two:
For more information on JDOM, see
http://www.jdom.org/.
For more information on dom4j, see
http://dom4j.org/.
Document Type Definition
The DTD specification is actually part of the XML specification, rather than a separate entity. On the other hand, it is optional--you can write an XML document without it. And there are a number of Schema Standards proposals that offer more flexible alternatives. So it is treated here as though it were a separate specification.
A DTD specifies the kinds of tags that can be included in your XML document, and the valid arrangements of those tags. You can use the DTD to make sure you don't create an invalid XML structure. You can also use it to make sure that the XML structure you are reading (or that got sent over the net) is indeed valid.
Unfortunately, it is difficult to specify a DTD for a complex document in such a way that it prevents all invalid combinations and allows all the valid ones. So constructing a DTD is something of an art. The DTD can exist at the front of the document, as part of the prolog. It can also exist as a separate entity, or it can be split between the document prolog and one or more additional entities.
However, while the DTD mechanism was the first method defined for specifying valid document structure, it was not the last. Several newer schema specifications have been devised. You'll learn about those momentarily.
The namespace standard lets you write an XML document that uses two or more sets of XML tags in modular fashion. Suppose for example that you created an XML-based parts list that uses XML descriptions of parts supplied by other manufacturers (online!). The "price" data supplied by the subcomponents would be amounts you want to total up, while the "price" data for the structure as a whole would be something you want to display. The namespace specification defines mechanisms for qualifying the names so as to eliminate ambiguity. That lets you write programs that use information from other sources and do the right things with it.
The latest information on namespaces can be found at
http://www.w3.org/TR/REC-xml-names.
Extensible Stylesheet Language
The XML standard specifies how to identify data, not how to display it. HTML, on the other hand, told how things should be displayed without identifying what they were. The XSL standard has two parts, XSLT (the transformation standard, described next) and XSL-FO (the part that covers formatting objects, also known as flow objects). XSL-FO gives you the ability to define multiple areas on a page and then link them together. When a text stream is directed at the collection, it fills the first area and then "flows" into the second when the first area is filled. Such objects are used by newsletters, catalogs, and periodical publications.
The latest W3C work on XSL is at
http://www.w3.org/TR/WD-xsl.
Extensible Stylesheet Language for Transformations
The XSLT transformation standard is essentially a translation mechanism that lets you specify what to convert an XML tag into so that it can be displayed--for example, in HTML. Different XSL formats can then be used to display the same data in different ways, for different uses. (The XPATH standard is an addressing mechanism that you use when constructing transformation instructions, in order to specify the parts of the XML structure you want to transform.)
A DTD makes it possible to validate the structure of relatively simple XML documents, but that's as far as it goes.
A DTD can't restrict the content of elements, and it can't specify complex relationships. For example, it is impossible to specify that a <heading> for a <book> must have both a <title> and an <author>, while a <heading> for a <chapter> only needs a <title>. In a DTD, you only get to specify the structure of the <heading> element one time. There is no context-sensitivity, because a DTD specification is not hierarchical.
For example, for a mailing address that contains several "parsed character data" (PCDATA) elements, the DTD might look something like this:
<!ELEMENT mailAddress (name, address, zipcode)> <!ELEMENT name (#PCDATA)> <!ELEMENT address (#PCDATA)> <!ELEMENT zipcode (#PCDATA)>
As you can see, the specifications are linear. So if you need another "name" element in the DTD, you need a different identifier for it. You could not simply call it "name" without conflicting with the <name> element defined for use in a <mailAddress>.
Another problem with the non hierarchical nature of DTD
specifications is that it is not clear what comments are meant to explain. A
comment at the top like might be intended to apply to the whole structure, or it
might be intended only for the first item. Finally, DTDs do not allow you to
formally specify field-validation criteria, such as the 5-digit (or 5 and 4)
limitation for the zipcode field.
Finally, a DTD uses syntax which is substantially different from XML, so it can't be processed with a standard XML parser. That means you can't read a DTD into a DOM, for example, modify it, and then write it back out again.
To remedy these shortcomings, a number of proposals have been made for a more database-like, hierarchical "schema" that specifies validation criteria. The major proposals are shown below.
A large, complex standard that has two parts. One part specifies structure relationships. (This is the largest and most complex part.) The other part specifies mechanisms for validating the content of XML elements by specifying a (potentially very sophisticated) datatype for each element. The good news is that XML Schema for Structures lets you specify virtually any relationship you can conceive. The bad news is that it is very difficult to implement, and it's hard to learn. Most of the alternatives provide for simpler structure definitions, while incorporating XML Schema's datatyping mechanisms.
For more information on XML Schema, see the W3C specs XML
Schema (Structures) and XML Schema (Datatypes), as well as other information
accessible at
http://www.w3c.org/XML/Schema.
REgular LAnguage description for XML (Next Generation)
Simpler than XML Structure Schema, RELAX NG is an emerging standard under the auspices of OASIS (Organization for the Advancement of Structured Information Systems). It may become an ISO standard in the near future, as well.
RELAX NG uses regular expression patterns to express constraints on structure relationships, and it is uses XML Schema datatyping mechanisms to express content constraints. This standard also uses XML syntax, and it includes a DTD to RELAX converter. (It's "next generation" because it's a newer version of the RELAX schema mechanism that integrates TREX.)
For more information on RELAX NG, see
http://www.oasis-open.org/committees/relax-ng/
Tree Regular Expressions for XML
A means of expressing validation criteria by describing a pattern for the structure and content of an XML document. Now part of the RELAX NG specification.
For more information on TREX, see
http://www.thaiopensource.com/trex/.
Schema for Object-oriented XML
SOX is a schema proposal that includes extensible data types, namespaces, and embedded documentation.
For more information on SOX, see
http://www.w3.org/TR/NOTE-SOX.
Schema for Object-oriented XML
An assertion-based schema mechanism that allows for sophisticated validation.
For more information on the Schematron validation mechanism,
see
http://www.ascc.net/xml/resource/schematron/schematron.html.
Arguably the two greatest benefits provided by HTML were the ability to link between documents, and the ability to create simple formatted documents (and, eventually, very complex formatted documents). The following standards aim at preserving the benefits of HTML in the XML arena, and to adding additional functionality, as well.
These specifications provide a variety of powerful linking mechanisms, and are sure to have a big impact on how XML documents are used.
XLink
The XLink protocol is a specification for handling links between XML documents. This specification allows for some pretty sophisticated linking, including two-way links, links to multiple documents, "expanding" links that insert the linked information into your document rather than replacing your document with a new page, links between two documents that are created in a third, independent document, and indirect links (so you can point to an "address book" rather than directly to the target document--updating the address book then automatically changes any links that use it).
XML Base
This standard defines an attribute for XML documents that defines a "base" address, that is used when evaluating a relative address specified in the document. (So, for example, a simple file name would be found in the base-address directory.)
XPointer
In general, the XLink specification targets a document or document-segment using its ID. The XPointer specification defines mechanisms for "addressing into the internal structures of XML documents", without requiring the author of the document to have defined an ID for that segment. To quote the spec, it provides for "reference to elements, character strings, and other parts of XML documents, whether or not they bear an explicit ID attribute".
For more information on the XML Linking standards, see
http://www.w3.org/XML/Linking.
The XHTML specification is a way of making XML documents that look and act like HTML documents. Since an XML document can contain any tags you care to define, why not define a set of tags that look like HTML? That's the thinking behind the XHTML specification, at any rate. The result of this specification is a document that can be displayed in browsers and also treated as XML data. The data may not be quite as identifiable as "pure" XML, but it will be a heck of a lot easier to manipulate than standard HTML, because XML specifies a good deal more regularity and consistency.
For example, every tag in a well-formed XML document must
either have an end-tag associated with it or it must end in
/>. So you might see
<p>...</p>, or you might
see <p/>, but you will never see
<p> standing by itself. The upshot of that requirement is that you never
have to program for the weird kinds of cases you see in HTML where, for example,
a <dt> tag might be terminated by
</DT>, by another
<DT>, by
<dd>, or by
</dl>. That makes it a lot easier
to write code!
The XHTML specification is a reformulation of HTML 4.0 into
XML. The latest information is at
http://www.w3.org/TR/xhtml1.
When you start looking down the road five or six years, and
visualize how the information on the Web will begin to turn into one huge
knowledge base (the "semantic Web"). For the latest on the semantic Web, visit
http://www.w3.org/2001/sw/.
In the meantime, here are the fundamental standards you'll want to know about:
Resource Description Framework
RDF is a standard for defining
meta data--information that describes what a particular data item is, and
specifies how it can be used. Used in conjunction with the XHTML specification,
for example, or with HTML pages, RDF could be used to describe the content of
the pages. For example, if your browser stored your ID information as
FIRSTNAME,
LASTNAME, and
EMAIL, an RDF description could make it possible to
transfer data to an application that wanted
NAME and
EMAILADDRESS. Just think: One day you may not need to
type your name and address at every Web site you visit!
For the latest information on RDF, see
http://www.w3.org/TR/REC-rdf-syntax.
RDF Schema allows the specification of consistency rules and additional information that describe how the statements in a Resource Description Framework (RDF) should be interpreted.
For more information on the RDF Schema recommendation, see
http://www.w3.org/TR/rdf-schema.
XML Topic Maps
In many ways a simpler, more readily usable knowledge-representation than RDF, the topic maps standard is one worth watching. So far, RDF is the W3C standard for knowledge representation, but topic maps could possibly become the "developer's choice" among knowledge representation standards.
For more information on XML Topic Maps,
http://www.topicmaps.org/xtm/index.html. For information on topic
maps and the Web, see
http://www.topicmaps.org/.
The following standards and proposals build on XML. Since XML is basically a language-definition tool, these specifications use it to define standardized languages for specialized purposes.
These standards define mechanisms for producing extremely complex documents--books, journals, magazines, and the like--using XML.
Synchronized Multimedia Integration Language
SMIL is a W3C recommendation that covers audio, video, and animations. It also addresses the difficult issue of synchronizing the playback of such elements.
For more information on SMIL, see
http://www.w3.org/TR/REC-smil.
Mathematical Markup Language
MathML is a W3C recommendation that deals with the representation of mathematical formulas.
For more information on MathML, see
http://www.w3.org/TR/REC-MathML.
Scalable Vector Graphics
SVG is a W3C working draft that covers the representation of vector graphic images. (Vector graphic images that are built from commands that say things like "draw a line (square, circle) from point xi to point m,n" rather than encoding the image as a series of bits. Such images are more easily scalable, although they typically require more processing time to render.)
For more information on SVG, see
http://www.w3.org/TR/WD-SVG.
Drawing Meta Language
DrawML is a W3C note that covers 2D images for technical illustrations. It also addresses the problem of updating and refining such images.
For more information on DrawML, see
http://www.w3.org/TR/NOTE-drawml.
These standards are aimed at using XML in the world of business-to-business (B2B) and business-to-consumer (B2C) commerce.
Information and Content Exchange
ICE is a protocol for use by content syndicators and their subscribers. It focuses on "automating content exchange and reuse, both in traditional publishing contexts and in business-to-business relationships".
For more information on ICE, see
http://www.w3.org/TR/NOTE-ice.
Electronic Business with XML
This standard aims at creating a modular electronic business framework using XML. It is the product of a joint initiative by the United Nations (UN/CEFACT) and the Organization for the Advancement of Structured Information Systems (OASIS).
For more information on ebXML, see
http://www.ebxml.org/.
Commerce XML
cxml is a RosettaNet (www.rosettanet.org)
standard for setting up interactive online catalogs for different buyers, where
the pricing and product offerings are company specific. Includes mechanisms to
handle purchase orders, change orders, status updates, and shipping
notifications.
For more information on cxml, see
http://www.cxml.org/
Common Business Library
CBL is a library of element and attribute definitions
maintained by CommerceNet (www.commerce.net).
For more information on CBL and a variety of other initiatives
that work together to enable eCommerce applications, see
http://www.commerce.net/projects/currentprojects/eco/wg/eCo_Framework_Specifications.html.
Universal Business Language
An OASIS initiative aimed at compiling a standard library of XML business documents (purchase orders, invoices, etc.) that are defined with XML Schema definitions.
Generating XML Data
This section also takes you step by step through the process of constructing an XML document. Along the way, you'll gain experience with the XML components you'll typically use to create your data structures.
Writing a Simple XML File
You'll start by writing the kind of XML data you could use for a slide presentation. In this exercise, you'll use your text editor to create the data in order to become comfortable with the basic format of an XML file. You'll be using this file and extending it in later exercises.
Creating the File
Using a standard text editor, create a file called
slideSample.xml.
Writing the Declaration
Next, write the declaration, which identifies the file as an XML document. The declaration starts with the characters
"<?", which is the standard XML identifier for a processing instruction. (You'll see other processing instructions later on in this tutorial.)This line identifies the document as an XML document that conforms to version 1.0 of the XML specification, and says that it uses the 8-bit Unicode character-encoding scheme.
Since the document has not been specified as "standalone", the parser assumes that it may contain references to other documents.
Adding a Comment
Comments are ignored by XML parsers. A program will never see them in fact, unless you activate special settings in the parser. Add the text highlighted below to put a comment into the file.
Defining the Root Element
After the declaration, every XML file defines exactly one element, known as the root element. Any other elements in the file are contained within that element. Enter the text highlighted below to define the root element for this file,
slideshow:
Note: XML element names are case-sensitive. The end-tag must exactly match the start-tag.
Adding Attributes to an Element
A slide presentation has a number of associated data items, none of which require any structure. So it is natural to define them as attributes of the
slideshowelement. Add the text highlighted below to set up some attributes:... <slideshowtitle="Sample Slide Show" date="Date of publication" author="Yours Truly"> </slideshow>When you create a name for a tag or an attribute, you can use hyphens (
"-"), underscores ("_"), colons (":"), and periods (".") in addition to characters and numbers. Unlike HTML, values for XML attributes are always in quotation marks, and multiple attributes are never separated by commas.
Note: Colons should be used with care or avoided altogether, because they are used when defining the namespace for an XML document.
Adding Nested Elements
XML allows for hierarchically structured data, which means that an element can contain other elements. Add the text highlighted below to define a slide element and a title element contained within it:
<slideshow ... ><!-- TITLE SLIDE --> <slide type="all"> <title>Wake up to WonderWidgets!</title> </slide></slideshow>Here you have also added a
typeattribute to the slide. The idea of this attribute is that slides could be earmarked for a mostly technical or mostly executive audience withtype="tech"ortype="exec", or identified as suitable for both withtype="all".More importantly, though, this example illustrates the difference between things that are more usefully defined as elements (the
titleelement) and things that are more suitable as attributes (thetypeattribute). The visibility heuristic is primarily at work here. The title is something the audience will see. So it is an element. The type, on the other hand, is something that never gets presented, so it is an attribute. Another way to think about that distinction is that an element is a container, like a bottle. The type is a characteristic of the container (is it tall or short, wide or narrow). The title is a characteristic of the contents (water, milk, or tea). These are not hard and fast rules, of course, but they can help when you design your own XML structures.Adding HTML-Style Text
Since XML lets you define any tags you want, it makes sense to define a set of tags that look like HTML. The XHTML standard does exactly that, in fact. You'll see more about that towards the end of the SAX tutorial. For now, type the text highlighted below to define a slide with a couple of list item entries that use an HTML-style
<em>tag for emphasis (usually rendered as italicized text):... <!-- TITLE SLIDE --> <slide type="all"> <title>Wake up to WonderWidgets!</title> </slide><!-- OVERVIEW --> <slide type="all"> <title>Overview</title> <item>Why <em>WonderWidgets</em> are great</item> <item>Who <em>buys</em> WonderWidgets</item> </slide></slideshow>Note that defining a title element conflicts with the XHTML element that uses the same name. We'll discuss the mechanism that produces the conflict (the DTD), along with possible solutions, later on in this tutorial.
Adding an Empty Element
One major difference between HTML and XML, though, is that all XML must be well-formed -- which means that every tag must have an ending tag or be an empty tag. You're getting pretty comfortable with ending tags, by now. Add the text highlighted below to define an empty list item element with no contents:
... <!-- OVERVIEW --> <slide type="all"> <title>Overview</title> <item>Why <em>WonderWidgets</em> are great</item><item/><item>Who <em>buys</em> WonderWidgets</item> </slide> </slideshow>Note that any element can be empty element. All it takes is ending the tag with
"/>"instead of">". You could do the same thing by entering<item></item>, which is equivalent.
Note: Another factor that makes an XML file well-formed is proper nesting. So
<b><i>some_text</i></b>is well-formed, because the<i>...</i>sequence is completely nested within the<b>..</b>tag. This sequence, on the other hand, is not well-formed:<b><i>some_text</b></i>.
The Finished Product
Here is the completed version of the XML file:
<?xml version='1.0' encoding='utf-8'?> <!-- A SAMPLE set of slides --> <slideshow title="Sample Slide Show" date="Date of publication" author="Yours Truly" > <!-- TITLE SLIDE --> <slide type="all"> <title>Wake up to WonderWidgets!</title> </slide> <!-- OVERVIEW --> <slide type="all"> <title>Overview</title> <item>Why <em>WonderWidgets</em> are great</item> <item/> <item>Who <em>buys</em> WonderWidgets</item> </slide </slideshow>Save a copy of this file as
slideSample01.xml, so you can use it as the initial data structure when experimenting with XML programming operations.Writing Processing Instructions
It sometimes makes sense to code application-specific processing instructions in the XML data. In this exercise, you'll add a processing instruction to your
slideSample.xmlfile.
As you saw in Processing Instructions, the format for a processing instruction is
<?target data?>, where "target" is the target application that is expected to do the processing, and "data" is the instruction or information for it to process. Add the text highlighted below to add a processing instruction for a mythical slide presentation program that will query the user to find out which slides to display (technical, executive-level, or all):<slideshow ... ><!-- PROCESSING INSTRUCTION --> <?my.presentation.Program QUERY="exec, tech, all"?><!-- TITLE SLIDE -->Notes:
- The "data" portion of the processing instruction can contain spaces, or may even be null. But there cannot be any space between the initial
<?and the target identifier.- The data begins after the first space.
- Fully qualifying the target with the complete Web-unique package prefix makes sense, so as to preclude any conflict with other programs that might process the same data.
- For readability, it seems like a good idea to include a colon (:) after the name of the application, like this:
The colon makes the target name into a kind of "label" that identifies the intended recipient of the instruction. However, while the w3c spec allows ":" in a target name, some versions of IE5 consider it an error. For this tutorial, then, we avoid using a colon in the target name.
Save a copy of this file as
slideSample02.xml, so you can use it when experimenting with processing instructions.Introducing an Error
The parser can generate one of three kinds of errors: fatal error, error, and warning. In this exercise, you'll make a simple modification to the XML file to introduce a fatal error. Then you'll see how it's handled in the Echo app.
One easy way to introduce a fatal error is to remove the final
"/"from the emptyitemelement to create a tag that does not have a corresponding end tag. That constitutes a fatal error, because all XML documents must, by definition, be well formed. Do the following:
- Copy
slideSample02.xmltoslideSampleBad1.xml.- Edit
slideSampleBad1.xmland remove the character shown below:to produce:
... <item>Why <em>WonderWidgets</em> are great</item> <item> <item>Who <em>buys</em> WonderWidgets</item> ... Now you have a file that you can use to generate an error in any parser, any time. (XML parsers are required to generate a fatal error for this file, because the lack of an end-tag for the <item> element means that the XML structure is no longer well- formed.)Substituting and Inserting Text
In this section, you'll learn about:
- Handling Special Characters (
"<","&", and so on)- Handling Text with XML-style syntax
Handling Special Characters
In XML, an entity is an XML structure (or plain text) that has a name. Referencing the entity by name causes it to be inserted into the document in place of the entity reference. To create an entity reference, the entity name is surrounded by an ampersand and a semicolon, like this:
Later, when you learn how to write a DTD, you'll see that you can define your own entities, so that
&yourEntityName;expands to all the text you defined for that entity. For now, though, we'll focus on the predefined entities and character references that don't require any special definitions.Predefined Entities
An entity reference like
&contains a name (in this case, "amp") between the start and end delimiters. The text it refers to (&) is substituted for the name, like a macro in a programming language. Table 2-1 shows the predefined entities for special characters.
Character References
A character reference like
“contains a hash mark (#) followed by a number. The number is the Unicode value for a single character, such as 65 for the letter "A", 147 for the left-curly quote, or 148 for the right-curly quote. In this case, the "name" of the entity is the hash mark followed by the digits that identify the character.Using an Entity Reference in an XML Document
Suppose you wanted to insert a line like this in your XML document:
The problem with putting that line into an XML file directly is that when the parser sees the left-angle bracket (<), it starts looking for a tag name, which throws off the parse. To get around that problem, you put
<in the file, instead of"<".
Add the text highlighted below to your
slideSample.xmlfile, and save a copy of it for future use asslideSample03.xml:<!-- OVERVIEW --> <slide type="all"> <title>Overview</title> ... </slide><slide type="exec"> <title>Financial Forecast</title> <item>Market Size < predicted</item> <item>Anticipated Penetration</item> <item>Expected Revenues</item> <item>Profit Margin </item> </slide></slideshow>When you use an XML parser to echo this data, you will see the desired output:
You see an angle bracket ("<") where you coded "<", because the XML parser converts the reference into the entity it represents, and passes that entity to the application.
Handling Text with XML-Style Syntax
When you are handling large blocks of XML or HTML that include many of the special characters, it would be inconvenient to replace each of them with the appropriate entity reference. For those situations, you can use a
CDATAsection.
A
CDATAsection works like<pre>...</pre>in HTML, only more so--all whitespace in aCDATAsection is significant, and characters in it are not interpreted as XML. ACDATAsection starts with<![CDATA[and ends with]]>.Add the text highlighted below to your
slideSample.xmlfile to define aCDATAsection for a fictitious technical slide, and save a copy of the file asslideSample04.xml:...<slide type="tech"> <title>How it Works</title> <item>First we fozzle the frobmorten</item> <item>Then we framboze the staten</item> <item>Finally, we frenzle the fuznaten</item> <item><![CDATA[Diagram: frobmorten <--------------- fuznaten | <3> ^ | <1> | <1> = fozzle V | <2> = framboze Staten--------------------+ <3> = frenzle <2> ]]></item> </slide></slideshow>When you echo this file with an XML parser, you'll see the following output:
Diagram: frobmorten <--------------fuznaten | <3> ^ | <1> | <1> = fozzle V | <2> = framboze staten----------------------+ <3> = frenzle <2>The point here is that the text in the
CDATAsection will have arrived as it was written. Since the parser doesn't treat the angle brackets as XML, they don't generate the fatal errors they would otherwise cause. (Because, if the angle brackets weren't in a CDATA section, the document would not be well-formed.)Creating a Document Type Definition
After the XML declaration, the document prolog can include a DTD, which lets you specify the kinds of tags that can be included in your XML document. In addition to telling a validating parser which tags are valid, and in what arrangements, a DTD tells both validating and nonvalidating parsers where text is expected, which lets the parser determine whether the whitespace it sees is significant or ignorable.
Basic DTD Definitions
To begin learning about DTD definitions, let's start by telling the parser where text is expected and where any text (other than whitespace) would be an error. (Whitespace in such locations is ignorable.)
Start by creating a file named
slideshow.dtd. Enter an XML declaration and a comment to identify the file, as shown below:Next, add the text highlighted below to specify that a
slideshowelement containsslideelements and nothing else:As you can see, the DTD tag starts with
<!followed by the tag name (ELEMENT). After the tag name comes the name of the element that is being defined (slideshow) and, in parentheses, one or more items that indicate the valid contents for that element. In this case, the notation says that aslideshowconsists of one or moreslideelements.Without the plus sign, the definition would be saying that a
slideshowconsists of a singleslideelement. The qualifiers you can add to an element definition are listed in Table 2-2.
?*+
You can include multiple elements inside the parentheses in a comma separated list, and use a qualifier on each element to indicate how many instances of that element may occur. The comma-separated list tells which elements are valid and the order they can occur in.
You can also nest parentheses to group multiple items. For an example, after defining an
imageelement (coming up shortly), you could declare that everyimageelement must be paired with atitleelement in a slide by specifying((image, title)+). Here, the plus sign applies to theimage/titlepair to indicate that one or more pairs of the specified items can occur.Defining Text and Nested Elements
Now that you have told the parser something about where not to expect text, let's see how to tell it where text can occur. Add the text highlighted below to define the
slide,title,item, andlistelements:<!ELEMENT slideshow (slide+)><!ELEMENT slide (title, item*)> <!ELEMENT title (#PCDATA)> <!ELEMENT item (#PCDATA | item)* >The first line you added says that a slide consists of a
titlefollowed by zero or moreitemelements. Nothing new there. The next line says that a title consists entirely of parsed character data (PCDATA). That's known as "text" in most parts of the country, but in XML-speak it's called "parsed character data". (That distinguishes it fromCDATAsections, which contain character data that is not parsed.) The"#"that precedesPCDATAindicates that what follows is a special word, rather than an element name.The last line introduces the vertical bar (
|), which indicates an or condition. In this case, eitherPCDATAor anitemcan occur. The asterisk at the end says that either one can occur zero or more times in succession. The result of this specification is known as a mixed-content model, because any number ofitemelements can be interspersed with the text. Such models must always be defined with#PCDATAspecified first, some number of alternate items divided by vertical bars (|), and an asterisk (*) at the end.Save a copy of this DTD as slideSample1a.dtd, for use when experimenting with basic DTD processing.
Limitations of DTDs
It would be nice if we could specify that an
itemcontains either text, or text followed by one or more list items. But that kind of specification turns out to be hard to achieve in a DTD. For example, you might be tempted to define anitemlike this:That would certainly be accurate, but as soon as the parser sees #PCDATA and the vertical bar, it requires the remaining definition to conform to the mixed-content model. This specification doesn't, so you get can error that says:
Illegal mixed content model for 'item'. Found ( ...,where the hex character 28 is the angle bracket the ends the definition.Trying to double-define the item element doesn't work, either. A specification like this:
produces a "duplicate definition" warning when the validating parser runs. The second definition is, in fact, ignored. So it seems that defining a mixed content model (which allows
itemelements to be interspersed in text) is about as good as we can do.In addition to the limitations of the mixed content model mentioned above, there is no way to further qualify the kind of text that can occur where
PCDATAhas been specified. Should it contain only numbers? Should be in a date format, or possibly a monetary format? There is no way to say in the context of a DTD.Finally, note that the DTD offers no sense of hierarchy. The definition for the
titleelement applies equally to aslidetitle and to anitemtitle. When we expand the DTD to allow HTML-style markup in addition to plain text, it would make sense to restrict the size of anitemtitle compared to aslidetitle, for example. But the only way to do that would be to give one of them a different name, such as "item-title". The bottom line is that the lack of hierarchy in the DTD forces you to introduce a "hyphenation hierarchy" (or its equivalent) in your namespace. All of these limitations are fundamental motivations behind the development of schema-specification standards.Special Element Values in the DTD
Rather than specifying a parenthesized list of elements, the element definition could use one of two special values:
ANYorEMPTY. TheANYspecification says that the element may contain any other defined element, orPCDATA. Such a specification is usually used for the root element of a general-purpose XML document such as you might create with a word processor. Textual elements could occur in any order in such a document, so specifyingANYmakes sense.The
EMPTYspecification says that the element contains no contents. So the DTD for e-mail messages that let you "flag" the message with<flag/>might have a line like this in the DTD:Referencing the DTD
In this case, the DTD definition is in a separate file from the XML document. That means you have to reference it from the XML document, which makes the DTD file part of the external subset of the full Document Type Definition (DTD) for the XML file. As you'll see later on, you can also include parts of the DTD within the document. Such definitions constitute the local subset of the DTD.
To reference the DTD file you just created, add the line highlighted below to your
slideSample.xmlfile, and save a copy of the file asslideSample05.xml:Again, the DTD tag starts with
"<!". In this case, the tag name,DOCTYPE, says that the document is aslideshow, which means that the document consists of theslideshowelement and everything within it:This tag defines the
slideshowelement as the root element for the document. An XML document must have exactly one root element. This is where that element is specified. In other words, this tag identifies the document content as aslideshow.The
DOCTYPEtag occurs after the XML declaration and before the root element. TheSYSTEMidentifier specifies the location of the DTD file. Since it does not start with a prefix likehttp:/orfile:/, the path is relative to the location of the XML document. Remember thesetDocumentLocatormethod? The parser is using that information to find the DTD file, just as your application would to find a file relative to the XML document. APUBLICidentifier could also be used to specify the DTD file using a unique name--but the parser would have to be able to resolve itThe
DOCTYPEspecification could also contain DTD definitions within the XML document, rather than referring to an external DTD file. Such definitions would be contained in square brackets, like this:You'll take advantage of that facility in a moment to define some entities that can be used in the document.
Documents and Data
Earlier, you learned that one reason you hear about XML documents, on the one hand, and XML data, on the other, is that XML handles both comfortably, depending on whether text is or is not allowed between elements in the structure.
In the sample file you have been working with, the
slideshowelement is an example of a data element--it contains only subelements with no intervening text. Theitemelement, on the other hand, might be termed a document element, because it is defined to include both text and subelements.As you work through this tutorial, you will see how to expand the definition of the title element to include HTML-style markup, which will turn it into a document element as well.
Defining Attributes and Entities in the DTD
The DTD you've defined so far is fine for use with the nonvalidating parser. It tells where text is expected and where it isn't, which is all the nonvalidating parser is going to pay attention to. But for use with the validating parser, the DTD needs to specify the valid attributes for the different elements. You'll do that in this section, after which you'll define one internal entity and one external entity that you can reference in your XML file.
Defining Attributes in the DTD
Let's start by defining the attributes for the elements in the slide presentation.
Add the text highlighted below to define the attributes for the
slideshowelement:<!ELEMENT slideshow (slide+)><!ATTLIST slideshow title CDATA #REQUIRED date CDATA #IMPLIED author CDATA "unknown" ><!ELEMENT slide (title, item*)>The DTD tag
ATTLISTbegins the series of attribute definitions. The name that followsATTLISTspecifies the element for which the attributes are being defined. In this case, the element is theslideshowelement. (Note once again the lack of hierarchy in DTD specifications.)Each attribute is defined by a series of three space-separated values. Commas and other separators are not allowed, so formatting the definitions as shown above is helpful for readability. The first element in each line is the name of the attribute:
title,date, orauthor, in this case. The second element indicates the type of the data:CDATAis character data--unparsed data, once again, in which a left-angle bracket (<) will never be construed as part of an XML tag. Table 2-3 presents the valid choices for the attribute type.
(value1 | value2 | ...)CDATAIDIDREFIDREFSENTITYENTITIESNMTOKENNMTOKENSNOTATION
*This is a rapidly obsolescing specification which will be discussed in greater length towards the end of this section.
When the attribute type consists of a parenthesized list of choices separated by vertical bars, the attribute must use one of the specified values. For an example, add the text highlighted below to the DTD:
<!ELEMENT slide (title, item*)><!ATTLIST slide type (tech | exec | all) #IMPLIED ><!ELEMENT title (#PCDATA)> <!ELEMENT item (#PCDATA | item)* >This specification says that the
slideelement'stypeattribute must be given astype="tech",type="exec", ortype="all". No other values are acceptable. (DTD-aware XML editors can use such specifications to present a pop-up list of choices.)The last entry in the attribute specification determines the attributes default value, if any, and tells whether or not the attribute is required. Table 2-4 shows the possible choices.
#REQUIRED#IMPLIED#FIXED"fixedValue"
Finally, save a copy of the DTD as
slideshow1b.dtd, for use when experimenting with attribute definitions.Defining Entities in the DTD
So far, you've seen predefined entities like
&and you've seen that an attribute can reference an entity. It's time now for you to learn how to define entities of your own.
Add the text highlighted below to the
DOCTYPEtag in your XML file:<!DOCTYPE slideshow SYSTEM "slideshow.dtd" [<!ENTITY product "WonderWidget"> <!ENTITY products "WonderWidgets"> ]>The
ENTITYtag name says that you are defining an entity. Next comes the name of the entity and its definition. In this case, you are defining an entity named "product" that will take the place of the product name. Later when the product name changes (as it most certainly will), you will only have to change the name one place, and all your slides will reflect the new value.The last part is the substitution string that replaces the entity name whenever it is referenced in the XML document. The substitution string is defined in quotes, which are not included when the text is inserted into the document.
Just for good measure, we defined two versions, one singular and one plural, so that when the marketing mavens come up with "Wally" for a product name, you will be prepared to enter the plural as "Wallies" and have it substituted correctly.
Note: Truth be told, this is the kind of thing that really belongs in an external DTD. That way, all your documents can reference the new name when it changes. But, hey, this is an example...
Now that you have the entities defined, the next step is to reference them in the slide show. Make the changes highlighted below to do that:
<slideshow title="WonderWidget&product;Slide Show" ... <!-- TITLE SLIDE --> <slide type="all"> <title>Wake up to WonderWidgets&products;!</title> </slide> <!-- OVERVIEW --> <slide type="all"> <title>Overview</title> <item>Why <em>WonderWidgets&products;</em> are great</item> <item/> <item>Who <em>buys</em> WonderWidgets&products;</item> </slide>The points to notice here are that entities you define are referenced with the same syntax (
&entityName;) that you use for predefined entities, and that the entity can be referenced in an attribute value as well as in an element's contents.When you echo this version of the file with an XML parser, here is the kind of thing you'll see:
Note that the product name has been substituted for the entity reference.
To finish, save a copy of the file as
slideSample06.xml.Additional Useful Entities
Here are several other examples for entity definitions that you might find useful when you write an XML document:
<!ENTITY ldquo "“"> <!-- Left Double Quote --> <!ENTITY rdquo "”"> <!-- Right Double Quote --> <!ENTITY trade "™"> <!-- Trademark Symbol (TM) --> <!ENTITY rtrade "®"> <!-- Registered Trademark (R) --> <!ENTITY copyr "©"> <!-- Copyright Symbol -->Referencing External Entities
You can also use the
SYSTEMorPUBLICidentifier to name an entity that is defined in an external file. You'll do that now.
To reference an external entity, add the text highlighted below to the
DOCTYPEstatement in your XML file:<!DOCTYPE slideshow SYSTEM "slideshow.dtd" [ <!ENTITY product "WonderWidget"> <!ENTITY products "WonderWidgets"><!ENTITY copyright SYSTEM "copyright.xml">]>This definition references a copyright message contained in a file named
copyright.xml. Create that file and put some interesting text in it, perhaps something like this:<!-- A SAMPLE copyright --> This is the standard copyright message that our lawyers make us put everywhere so we don't have to shell out a million bucks every time someone spills hot coffee in their lap...Finally, add the text highlighted below to your
slideSample.xmlfile to reference the external entity, and save a copy of the file asslideSample07.html:<!-- TITLE SLIDE --> ... </slide><!-- COPYRIGHT SLIDE --> <slide type="all"> <item>©right;</item> </slide>You could also use an external entity declaration to access a servlet that produces the current date using a definition something like this:
You would then reference that entity the same as any other entity:
When you echo the latest version of the slide presentation with an XML parser, here is what you'll see:
... <slide type="all"> <item> This is the standard copyright message that our lawyers make us put everywhere so we don't have to shell out a million bucks every time someone spills hot coffee in their lap... </item> </slide> ...You'll notice that the newline which follows the comment in the file is echoed as a character, but that the comment itself is ignored. That is the reason that the copyright message appears to start on the next line after the
<item>element, instead of on the same line--the first character echoed is actually the newline that follows the comment.Summarizing Entities
An entity that is referenced in the document content, whether internal or external, is termed a general entity. An entity that contains DTD specifications that are referenced from within the DTD is termed a parameter entity. (More on that later.)
An entity which contains XML (text and markup), and which is therefore parsed, is known as a parsed entity. An entity which contains binary data (like images) is known as an unparsed entity. (By its very nature, it must be external.) We'll be discussing references to unparsed entities in the next section of this tutorial.
Referencing Binary Entities
This section discusses the options for referencing binary files like image files and multimedia data files.
Using a MIME Data Type
There are two ways to go about referencing an unparsed entity like a binary image file. One is to use the DTD's
NOTATION-specification mechanism. However, that mechanism is a complex, non-intuitive holdover that mostly exists for compatibility with SGML documents. We will have occasion to discuss it in a bit more depth when we look at theDTDHandlerAPI, but suffice it for now to say that the combination of the recently defined XML namespaces standard, in conjunction with the MIME data types defined for electronic messaging attachments, together provide a much more useful, understandable, and extensible mechanism for referencing unparsed external entities.
To set up the slideshow to use image files, add the text highlighted below to your
slideshow1b.dtdfile:<!ELEMENT slide (image?, title, item*)> <!ATTLIST slide type (tech | exec | all) #IMPLIED > <!ELEMENT title (#PCDATA)> <!ELEMENT item (#PCDATA | item)* ><!ELEMENT image EMPTY> <!ATTLIST image alt CDATA #IMPLIED src CDATA #REQUIRED type CDATA "image/gif" >These modifications declare
imageas an optional element in aslide, define it as empty element, and define the attributes it requires. Theimagetag is patterned after the HTML 4.0 tag,img, with the addition of an image-type specifier,type. (Theimgtag is defined in the HTML 4.0 Specification.)The
imagetag's attributes are defined by theATTLISTentry. Thealtattribute, which defines alternate text to display in case the image can't be found, accepts character data (CDATA). It has an "implied" value, which means that it is optional, and that the program processing the data knows enough to substitute something like "Image not found". On the other hand, thesrcattribute, which names the image to display, is required.The
typeattribute is intended for the specification of a MIME data type, as defined at http://www.iana.org/assignments/media-types/. It has a default value:image/gif.
Note: It is understood here that the character data (
CDATA) used for the type attribute will be one of the MIME data types. The two most common formats are:image/gif, andimage/jpeg. Given that fact, it might be nice to specify an attribute list here, using something like:
type ("image/gif", "image/jpeg")
That won't work, however, because attribute lists are restricted to name tokens. The forward slash isn't part of the valid set of name-token characters, so this declaration fails. Besides that, creating an attribute list in the DTD would limit the valid MIME types to those defined today. Leaving it asCDATAleaves things more open ended, so that the declaration will continue to be valid as additional types are defined.
In the document, a reference to an image named "intro-pic" might look something like this:
The Alternative: Using Entity References
Using a MIME data type as an attribute of an element is a mechanism that is flexible and expandable. To create an external
ENTITYreference using the notation mechanism, you need DTDNOTATIONelements for jpeg and gif data. Those can of course be obtained from some central repository. But then you need to define a differentENTITYelement for each image you intend to reference! In other words, adding a new image to your document always requires both a new entity definition in the DTD and a reference to it in the document. Given the anticipated ubiquity of the HTML 4.0 specification, the newer standard is to use the MIME data types and a declaration likeimage, which assumes the application knows how to process such elements.Defining Parameter Entities and Conditional Sections
Just as a general entity lets you reuse XML data in multiple places, a parameter entity lets you reuse parts of a DTD in multiple places. In this section of the tutorial, you'll see how to define and use parameter entities. You'll also see how to use parameter entities with conditional sections in a DTD.
Creating and Referencing a Parameter Entity
Recall that the existing version of the slide presentation could not be validated because the document used
<em>tags, and those are not part of the DTD. In general, we'd like to use a whole variety of HTML-style tags in the text of a slide, not just one or two, so it makes more sense to use an existing DTD for XHTML than it does to define all the tags we might ever need. A parameter entity is intended for exactly that kind of purpose.
Open your DTD file for the slide presentation and add the text highlighted below to define a parameter entity that references an external DTD file:
<!ELEMENT slide (image?, title?, item*)> <!ATTLIST slide ... ><!ENTITY % xhtml SYSTEM "xhtml.dtd"> %xhtml;<!ELEMENT title ...Here, you used an
<!ENTITY>tag to define a parameter entity, just as for a general entity, but using a somewhat different syntax. You included a percent sign (%) before the entity name when you defined the entity, and you used the percent sign instead of an ampersand when you referenced it.Also, note that there are always two steps for using a parameter entity. The first is to define the entity name. The second is to reference the entity name, which actually does the work of including the external definitions in the current DTD. Since the URI for an external entity could contain slashes (/) or other characters that are not valid in an XML name, the definition step allows a valid XML name to be associated with an actual document. (This same technique is used in the definition of namespaces, and anywhere else that XML constructs need to reference external documents.)
Notes:
- The DTD file referenced by this definition is
xhtml.dtd. You can either copy that file to your system or modify theSYSTEMidentifier in the<!ENTITY>tag to point to the correct URL.- This file is a small subset of the XHTML specification, loosely modeled after the Modularized XHTML draft, which aims at breaking up the DTD for XHTML into bite-sized chunks, which can then be combined to create different XHTML subsets for different purposes. When work on the modularized XHTML draft has been completed, this version of the DTD should be replaced with something better. For now, this version will suffice for our purposes.
The whole point of using an XHTML-based DTD was to gain access to an entity it defines that covers HTML-style tags like
<em>and<b>. Looking throughxhtml.dtdreveals the following entity, which does exactly what we want:This entity is a simpler version of those defined in the Modularized XHTML draft. It defines the HTML-style tags we are most likely to want to use -- emphasis, bold, and break, plus a couple of others for images and anchors that we may or may not use in a slide presentation. To use the
inlineentity, make the changes highlighted below in your DTD file:These changes replaced the simple
#PCDATAitem with theinlineentity. It is important to notice that#PCDATAis first in theinlineentity, and that inline is first wherever we use it. That is required by XML's definition of a mixed-content model. To be in accord with that model, you also had to add an asterisk at the end of thetitledefinition.Save the DTD as
slideshow2.dtd, for use when experimenting with parameter entities.
Note: The Modularized XHTML DTD defines both
inlineandInlineentities, and does so somewhat differently. Rather than specifying#PCDATA|em|b|a|img|Br, their definitions are more like(#PCDATA|em|b|a|img|Br)*. Using one of those definitions, therefore, looks more like this:
<!ELEMENT title %Inline; >
Conditional Sections
Before we proceed with the next programming exercise, it is worth mentioning the use of parameter entities to control conditional sections. Although you cannot conditionalize the content of an XML document, you can define conditional sections in a DTD that become part of the DTD only if you specify
include. If you specifyignore, on the other hand, then the conditional section is not included.Suppose, for example, that you wanted to use slightly different versions of a DTD, depending on whether you were treating the document as an XML document or as a SGML document. You could do that with DTD definitions like the following:
someExternal.dtd: <![ INCLUDE [ ... XML-only definitions ]]> <![IGNORE[ ... SGML-only definitions ]]> ... common definitionsThe conditional sections are introduced by
"<![", followed by theINCLUDEorIGNOREkeyword and another"[". After that comes the contents of the conditional section, followed by the terminator:"]]>". In this case, the XML definitions are included, and the SGML definitions are excluded. That's fine for XML documents, but you can't use the DTD for SGML documents. You could change the keywords, of course, but that only reverses the problem.The solution is to use references to parameter entities in place of the
INCLUDEandIGNOREkeywords:someExternal.dtd: <![%XML;[ ... XML-only definitions ]]> <![%SGML;[ ... SGML-only definitions ]]> ... common definitionsThen each document that uses the DTD can set up the appropriate entity definitions:
<!DOCTYPE foo SYSTEM "someExternal.dtd" [<!ENTITY % XML "INCLUDE" > <!ENTITY % SGML "IGNORE" >]> <foo> ... </foo>This procedure puts each document in control of the DTD. It also replaces the
INCLUDEandIGNOREkeywords with variable names that more accurately reflect the purpose of the conditional section, producing a more readable, self-documenting version of the DTD.Resolving A Naming Conflict
The XML structures you have created thus far have actually encountered a small naming conflict. It seems that
xhtml.dtddefines atitleelement which is entirely different from thetitleelement defined in the slideshow DTD. Because there is no hierarchy in the DTD, these two definitions conflict.
You could use XML namespaces to resolve the conflict. You'll take a look at that approach in the next section. Alternatively, you could use one of the more hierarchical schema proposals described in Schema Standards. The simplest way to solve the problem for now, though, is simply to rename the
titleelement inslideshow.dtd. To keep the two title elements separate, you'll create a "hyphenation hierarchy". Make the changes highlighted below to change the name of thetitleelement inslideshow.dtdtoslide-title:<!ELEMENT slide (image?,slide-title?, item*)> <!ATTLIST slide type (tech | exec | all) #IMPLIED > <!-- Defines the %inline; declaration --> <!ENTITY % xhtml SYSTEM "xhtml.dtd"> %xhtml; <!ELEMENTslide-title (%inline;)*>Save this DTD as
slideshow3.dtd.The next step is to modify the XML file to use the new element name. To do that, make the changes highlighted below:
... <slide type="all"> <slide-title>Wake up to ... </slide-title> </slide> ... <!-- OVERVIEW --> <slide type="all"> <slide-title>Overview</slide-title> <item>...Save a copy of this file as
slideSample09.xml.Using Namespaces
As you saw earlier, one way or another it is necessary to resolve the conflict between the
titleelement defined inslideshow.dtdand the one defined inxhtml.dtdwhen the same name is used for different purposes. In the previous exercise, you hyphenated the name in order to put it into a different "namespace". In this section, you'll see how to use the XML namespace standard to do the same thing without renaming the element.The primary goal of the namespace specification is to let the document author tell the parser which DTD or schema to use when parsing a given element. The parser can then consult the appropriate DTD or schema for an element definition. Of course, it is also important to keep the parser from aborting when a "duplicate" definition is found, and yet still generate an error if the document references an element like
titlewithout qualifying it (identifying the DTD or schema to use for the definition).
Note: Namespaces apply to attributes as well as to elements. In this section, we consider only elements. For more information on attributes, consult the namespace specification at
http://www.w3.org/TR/REC-xml-names/.
Defining a Namespace in a DTD
In a DTD, you define a namespace that an element belongs to by adding an attribute to the element's definition, where the attribute name is
xmlns("xml namespace"). For example, you could do that inslideshow.dtdby adding an entry like the following in thetitleelement's attribute-list definition:<!ELEMENT title (%inline;)*><!ATTLIST title xmlns CDATA #FIXED "http://www.example.com/slideshow" >Declaring the attribute as
FIXEDhas several important features:
- It prevents the document from specifying any non-matching value for the
xmlnsattribute.- The element defined in this DTD is made unique (because the parser understands the
xmlnsattribute), so it does not conflict with an element that has the same name in another DTD. That allows multiple DTDs to use the same element name without generating a parser error.- When a document specifies the
xmlnsattribute for a tag, the document selects the element definition with a matching attribute.To be thorough, every element name in your DTD would get the exact same attribute, with the same value. (Here, though, we're only concerned about the
titleelement.) Note, too, that you are using aCDATAstring to supply the URI. In this case, we've specified an URL. But you could also specify a URN, possibly by specifying a prefix likeurn:instead ofhttp:. (URNs are currently being researched. They're not seeing a lot of action at the moment, but that could change in the future.)Referencing a Namespace
When a document uses an element name that exists in only one of the
.DTDs or schemas it references, the name does not need to be qualified. But when an element name that has multiple definitions is used, some sort of qualification is a necessity.
Note: In point of fact, an element name is always qualified by it's default namespace, as defined by name of the DTD file it resides in. As long as there as is only one definition for the name, the qualification is implicit.
You qualify a reference to an element name by specifying the
xmlnsattribute, as shown here:The specified namespace applies to that element, and to any elements contained within it.
Defining a Namespace Prefix
When you only need one namespace reference, it's not such a big deal. But when you need to make the same reference several times, adding
xmlnsattributes becomes unwieldy. It also makes it harder to change the name of the namespace at a later date.The alternative is to define a namespace prefix, which as simple as specifying xmlns, a colon (:) and the prefix name before the attribute value, as shown here:
This definition sets up
SLas a prefix that can be used to qualify the current element name and any element within it. Since the prefix can be used on any of the contained elements, it makes the most sense to define it on the XML document's root element, as shown here.
Note: The namespace URI can contain characters which are not valid in an XML name, so it cannot be used as a prefix directly. The prefix definition associates an XML name with the URI, which allows the prefix name to be used instead. It also makes it easier to change references to the URI in the future.
When the prefix is used to qualify an element name, the end-tag also includes the prefix, as highlighted here:
<SL:slideshow xmlns:SL='http:/www.example.com/slideshow' ...> ... <slide> <SL:title>Overview</SL:title> </slide> ... </SL:slideshow>Finally, note that multiple prefixes can be defined in the same element, as shown here:
With this kind of arrangement, all of the prefix definitions are together in one place, and you can use them anywhere they are needed in the document. This example also suggests the use of URN to define the
xhtmlprefix, instead of an URL. That definition would conceivably allow the application to reference a local copy of the XHTML DTD or some mirrored version, with a potentially beneficial impact on performance.
