 | Level: Introductory Bob DuCharme (bob@snee.com), Solutions Architect, Innodata Isogen
12 Jun 2007 The XHTML 2 specification isn't finished, but it already has many advantages
over XHTML 1, including a greater structural richness that will make it more viable
than its predecessor as an editorial format to serve as the central schema for a
single-source publishing system. Without waiting for browser support of the new user
interface features in XHTML 2, people who do large- or small-scale publishing can
start to use these new features now.
About a year ago, an industry standards group asked me to do a presentation on
how XHTML 2 might be useful to publishers. I had no idea whether it would be
useful, but they were paying my expenses for a trip to New York, so I decided to look into it.
I didn't have to look hard. XHTML 2 adds enough structural sophistication to
XHTML to make it a viable format to create and store content, not just to deliver
it to browsers. When I say that XHTML 2 is already useful, I'm indulging in a bit
of hyperbole; many shops have perfectly sensible policies against using unfinished
standards, and XHTML 2 is still a Working Draft (see Resources for more information). Unlike nearly all HTML-related
standards, though, XHTML 2 can provide plenty of value well before any big-name
browsers support it, because of the way that it allows greater possibilities for storing content with richer, more sophisticated structures without deviating much from the set of HTML elements and attributes familiar to many.
The state of the XHTML: Where we are now
The W3C XHTML 1.0 standard (see Resources) created an
XML version of HTML. While browsers aren't picky about whether Web pages are
well-formed XML or not, Web site designers who are tired of doing things one way
for Firefox and another way for Microsoft™ Internet Explorer see more
value in standards. Many of the stylesheets at open source CSS collections such as Open Web Design and Open Source Web Design (see Resources for links to both) use XHTML 1 sample files for demonstration purposes, and I've heard Web designers who barely understand what well-formed means proudly proclaim that their sites are in XHTML. As Internet Explorer and Firefox support more CSS features, these Web designers move more of their design tricks into their CSS stylesheets, leaving simpler, more straightforward (and more easily reusable) XHTML in their base documents.
XHTML 1.1 (see Resources) added no new features, but
split XHTML into modules. This was valuable for two reasons. First, you could more
easily adopt a subset of it if you found value in certain modules but not others. For example, the Wireless Application Forum (WAP) had every reason to incorporate basic XHTML structures into its standard to deliver content to mobile phones, but it didn't want to allow WAP documents to incorporate user interface features such as image maps or edit module capabilities that made less sense on the small screen of a phone.
Another advantage of a modular architecture for a DTD or schema is that it makes it easier to plug in new modules specialized for your own applications. Combined with the ability to pick and choose existing modules, this has already brought a benefit to the publishing industry: the PRISM standards group for publishing industry metadata selected a subset of XHTML 1.1 and then added new modules with industry-specific vocabulary to ease the tracking of content through publishing workflows. (See Resources for more information on PRISM.)
You might compare the development of XHTML 1.1 to the straightening out of your basement: while you might not throw much out, by organizing things better, you can more easily use what you have and maybe even clear room to build a workbench that lets you create new things.
XHTML 1.1 has been a standard—or, in W3C parlance, a
Recommendation
—since May of 2001. XHTML 2.0's most recent
round was a new Working Draft in July of 2006. While it must still pass through
several more stages, the current availability of RELAX NG schemas (see Resources for a link) lets you create and use XHTML 2 documents now to speed your move to XHTML when the spec becomes a Recommendation. A simple XSLT stylesheet will convert these files to XHTML 1 for browser display, or you can use the CSS stylesheet now included with the XHTML 2 Working Draft (see Resources) to display these documents in a browser. (For now, Firefox seems to do a better job.)
XHTML 2: What's new?
XHTML 2 continues XHTML 1's work of cleaning up the existing syntax to make it
simpler, and also adds new features. It adds support for XForms, the more
sophisticated successor to the forms that have been in HTML for over ten years.
XHTML 2 also includes XML Events, which let you identify events to trigger
upon certain user interface actions, and thereby reduce the need to write out
scripts using JavaScript or ASP. These features will be interesting, especially
when the major browsers support them, but other features will be more interesting
to people who publish even before the browsers support XHTML 2:
-
A richer, more reusable structure
-
More device independence, accessibility, and semantics
-
Easier addition of metadata
Richer structure
Many publishers that store content in XML have always known that using an existing, standard schema (by which I mean a W3C Schema, a RELAX NG schema, or a DTD) was better than creating their own from scratch. They looked at DocBook and found it too complex; they looked at HTML or XHTML 1 and found it too simple. For many of them, XHTML 2 will hit a sweet spot between the richness of DocBook and the simplicity of XHTML 1 that makes it a perfectly good format for storing content, whether that content has to be converted to other formats for delivery in various media or not.
Listing 1 contains a sample XHTML 1 file, with its structure indicated by indentation.
Listing 1. Structure of an XHTML 1 file
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>My Web page</title>
</head>
<body>
<h1>My Web Page</h1>
<p>Here is my Web page.</p>
<h2>Section 1 of my Web page</h2>
<p>Here is section 1 my Web page.</p>
<h3>Section 1.1 of my Web page</h3>
<p>Here is a subsection of my Web page.</p>
<h2>Section 2 of my Web page</h2>
<p>Here is section 2 of my Web page.</p>
</body>
</html>
|
You don't see much indenting inside the body element
because there's not much structure there. A tree representation of this document
would show a body element with a lot of children and no
grandchildren, with the paragraph "Here is a subsection of my Web page" shown as a sibling of the main h1 title "My Web Page." The markup's only clue that this paragraph is part of a subsection is the fact that the most recent header preceding it, h3, has a bigger number than the earlier headers. No container element groups any headers with the content for which they serve as titles, unless you count the body element that wraps the h1 header and the rest of the Web page's displayable content. You could wrap a div element around each header/content combination, but, like the span element, div is a fairly generic grouping element. It can serve many purposes, such as indicating that certain paragraphs form a menu, or a sidebar, or another visual presentation element of a Web page, so you can't assume that its presence indicates a structural unit of content.
XHTML 2's new section and h
elements work together to let you create a richer structure that makes content
reuse easier. Listing 2 illustrates the XHTML 2 equivalent of the body element from Listing 1.
Listing 2. An XHTML 2 body element
<body>
<section>
<h>My Web Page</h>
<p>Here is my Web page.</p>
<section>
<h>Section 1 of my Web page</h>
<p>Here is section 1 my Web page.</p>
<section>
<h>Section 1.1 of my Web page</h>
<p>Here is a subsection of my Web page.</p>
</section>
</section>
<section>
<h>Section 2 of my Web page</h>
<p>Here is section 2 of my Web page.</p>
</section>
</section>
</body>
|
In this version, the "Here is a subsection" paragraph is a great-grandchild of the section element that has a "My Web Page" h element to show its main title—as it should be!
One advantage of this rich structure (and a key reason that XHTML 2 is a more
viable candidate than XHTML 1 to serve as the central format for a single-source
publishing system) is easier stream processing. If you need to process so much input that you can't load it all into memory before processing it—for example, if you prepare content for a CD-ROM—it's much easier for your process to figure out where each section ends in an XHTML 2 document. For example, imagine that you want to pull out all the sections that have the word "Beagle" in their title. Finding these titles is easy enough, but determining where the sections end is much more difficult in XHTML 1. Whether you process this XHTML with a stream-based interface, with XQuery, or with XSLT, clear delineation of where the sections end makes the extraction much easier.
Now, imagine that you extracted these sections because you will add them to a new
publication on beagles, and every section that you pull out has an h3 element as its header. Numbered XHTML 1 headers such as h3 are still legal in XHTML 2, but what if your new publication will
use these elements as main sections, or as subsections within a particular
chapter? You'd have to go back and change your h3
elements to h2 elements, or h4 elements, or whatever element identified their role in their new context. If they had been XHTML 2 h elements in the original document, with their hierarchical role indicated by the number of section ancestor elements each had (for example, note how the section 1.1 h element in Listing 2 above has three section headers ancestors, while the "My Web Page" h element only has one), you could plug them into a new document unchanged, with their role indicated by the nesting arrangement of the new document's section elements. CSS, XSLT, and other XML processing tools and standards all offer a way to treat elements of the same name differently depending on their nesting level, so you won't miss the numbers that were part of the XHTML 1 headers. When you consider the number of (X)HTML documents out there that have h2 and h3 elements but no h1 elements, or h1 and h3 elements but no h2 elements, it's clear that too many people weren't using them to indicate a proper hierarchy anyway.
The p element can also have more structure in XHTML 2. Imagine that I want to introduce some sample code in the middle of a sentence, like this:
If I want to continue the sentence after the sample code, XHTML 1 forces me to put the two halves of the split sentence into two different p elements, when semantically they're in the same paragraph. XHTML 2 lets you put sample code, bulleted and numbered lists, and many other block elements inside of a p element, letting your markup more accurately reflect your document's structure.
One more small step from presentation markup to structural markup is the renaming of the hr element to separator. The HTML Working Group found that the original name, which stood for horizontal rule, often fell into a gray area between structural and presentation markup. They had requests for a vertical rule from people writing in some Asian languages, and they saw many horizontal separators out there that weren't really rules (a slide presentation by HTML Working Group Chair Steven Pemberton points out several different variations in James Joyce's Ulysses; see Resources for a link to the presentation). This led them to rename the hr element to more accurately reflect its use and allow more flexibility in its presentation.
More device independence, accessibility, and semantics
These three goals actually overlap each other. A Web page that still makes sense
when read out loud by a text-to-speech translator is a Web page that isn't tied to
delivery on one platform, and it's a Web page that someone who is visually
impaired can understand more easily. As the XHTML 2 Working Draft notes:
New devices coming online, such as telephones, PDAs, tablets, televisions, and so on mean that it is imperative to have a design that allows you to author once and render in different ways on different devices, rather than authoring new versions of the document for each type of device.
Publishers need not look to the future to see the value of this. Device independence is what drew many of them to SGML before XML was invented, because it lets them publish the same content in print, on Web pages, and on CD-ROMs, as long as the editorial version of that content is stored with enough structure and semantic information to let automated routines convert it to each of the formats. I remember the snickers around my former employer's office eleven years ago when we heard that our competitor would be storing the editorial version of their content as HTML; with XHTML 2, it's not such a crazy idea.
If the existing semantics of XHTML 2's elements aren't enough for you, the new
role attribute, which can be added to just about any
element, can tell you more about the element's purpose. The XHTML 2 spec specifies
nine possible values for this attribute: banner, note, contentinfo, search, definition, secondary, main, seealso, and navigation. Role values such
as banner and navigation are
clearly more presentation-oriented, but values such as definition and note have semantics that are more useful in a publishing environment that prepares content for multiple media. You can even make up your own role values, as long as they're in their own namespace.
Easier addition of metadata
The W3C RDF standard lets you assign metadata to anything that you can identify
with a URL. The standard RDF/XML syntax for doing this, which has been around
since 1999, is complex and difficult enough to have scared many people off. By
using existing XHTML attributes and adding a few new ones, XHTML 2 lets you use
the new, simpler RDFa syntax to add metadata about documents and document components that have an about attribute to identify them. Listing 3 shows some examples in which span elements store the additional information necessary to embed the subject-predicate-object triples (which might be easier to think of as object ID-attribute name-attribute value triples) used to represent RDF metadata.
Listing 3. Encoding metadata with the span element
<section>
<span property="dc:subject" content="recipe"/>
<span property="fb:workflowStage" content="3a"/>
<h><span property="dc:title">
Carrion, My Wayward Son
</span></h>
<p><span property="dc:date" content="2007-05-15" datatype="xs:date>
May 15, 2007
</span></p>
</section>
</blockcode>
</section>
|
Because the RDFa markup in Listing 3 doesn't use any about attributes to name subjects, an RDFa processor will assume that the document itself is the subject of each triple, which is what we want—they're metadata about the document itself.
Assuming that the prefix dc is declared to represent the
Dublin Core namespace http://purl.org/dc/elements/1.1/, and that fb represents the mythical FooBar Company's
http://www.foobarco.com/ns/vocab# namespace, the RDFa markup in Listing 3 makes the following statements in a way that you can extract and load into a database of RDF triples:
-
This document has a Dublin Core subject of "recipe."
-
This document has a workflowStage value (a
customized bit of metadata for the company that created the document) of "3a."
-
This document has a Dublin Core title of "Carrion, My Wayward Son". For this
statement, the metadata value, or the object of the triple, is part of the
actual Web page, and not stored in a content
attribute like it is with the other span elements. With no need to specify a separate object and with the document itself serving as the subject, you have a useful triple of metadata here that was added to the document with just a span element that has a single attribute.
-
This document has a publication date of May 15, 2007. The actual value that will be stored is in the ISO 8601 standard format 2007-05-15. It even includes typing information: it's a W3C Schema date datatype (see Resources).
Much of the dream of the Semantic Web is to allow the use of Web page data both
as content to publish for people to read and as data for programs to read, as from
a database, as the dc:title example in Listing 3 demonstrates. The fb:workflowStage example demonstrates an additional advantage of
RDFa: you can add truly arbitrary metadata to your XHTML 2 documents, specialized
to how your own shop does things, which makes documents easier to track and reuse.
Using XHTML 2 now
You still have to wait a bit before you can use the newer user interface features
of XHTML 2m such as XML Events, but you have what you need now to experiment with
XHTML 2's new structural features. As an unfinished specification, it's still a
moving target, but it's now moving slowly. And with the schema and CSS stylesheet
currently available, you can try it and think about what advantages it might bring to your operation. In fact, I used it to write this article, with Emacs in nXML mode (see Resources) to drive context-sensitive XML editing off of XHTML 2's RELAX NG schema. Before I turned the article in, I converted it to conform to the developerWorks DTD with a simple XSLT stylesheet. By the time XHTML 2 becomes a standard Recommendation, I plan to be going at full speed with it.
Resources Learn
- The XHTML 2.0 technical report:
Monitor the progress from Working Draft to Recommendation at the primary source for information on XHTML 2.
-
CSS stylesheet: See the
stylesheet included with the XHTML 2 Working Draft.
-
XHTML 1.0 Recommendation: Check
out the W3C reformulation of HTML 4 as an XML 1.0 application, and three DTDs that correspond to the ones defined by HTML 4.
- W3C XHTML 1.1 Recommendation: Look
at the new XHTML document type that will serve as the basis for future document
types in the extended XHTML family.
- "The Web's future: XHTML
2.0" (Nicholas Chase, developerWorks, September 2002): Read this early "sneak peek" at XHTML 2.0 and how you might one day put it to use.
- "XHTML 2.0" (Edd
Dumbill, developerWorks, January 2006): Read the second of a two-part article on
the future of HTML as it describes many of XML 2.0's features.
- Read Chris Herboth's three-part developerWorks series, "Introduction to XForms", from September 2006:
-
W3C XForms Recommendation: See
how XForms separates presentation from content, allows reuse, gives strong typing. and
reduces the number of server round-trips as it offers device independence and reduced scripting.
- "XHTML2: Accessible, usable, device
independent and semantic:": Get a great overview of XHTML 2 in this 2005 slideshow by HTML Working Group chair Steven Pemberton and co-XHTML 2.0 spec editor Mark Birbeck.
-
XML Schema Part 2: See this W3C Recommendation for more information on the data types used by RDF and other standards.
-
Open Web
Design and Open Source Web Design: Find many
stylesheets in these open source CSS collections, including XHTML 1 sample files that demonstrate their use.
-
Wireless Application Forum: Find out about specs, publicly available materials, DTDs, schemas, and more.
-
PRISM: Learn about the standards group for publishing industry metadata.
-
IBM XML certification: Find out how you can become an IBM-Certified Developer in XML and related technologies.
-
XML technical library: See the developerWorks XML Zone for a wide range of technical articles and tips, tutorials, standards, and IBM Redbooks.
-
developerWorks technical events and webcasts: Stay current with technology in these sessions.
- The technology
bookstore: Browse for books on these and other technical topics.
Get products and technologies
-
nXML: TurnsGNU Emacs into a powerful XML editor.
-
RELAX NG schema for XHTML
2: Download and try RELAX NG with your XHTML.
-
IBM trial software: Build your next development project with trial software available for download directly from developerWorks.
Discuss
About the author | 
| | Bob DuCharme, a solutions architect at Innodata Isogen, was an XML "expert" when XML was a four-letter word. He's written four books and nearly one hundred online and print articles about information technology without using the word "functionality" in any of them. See http://www.snee.com/bob for more. |
Rate this page
| |
