XHTML Inside XML: Using XHTML in an XML Context

While supplementing the XHTML vocabulary with your own XML modules is a very useful approach for solving a lot of problems, there are also a lot of cases in which XHTML can provide a useful supplement to XML vocabularies. HTML is ubiquitous, well known, and supported by toolkits that make integrating it with some kinds of XML development easier. If XML documents need documentation, if they need a presentation vocabulary, or if they need to act as containers for Web documents, then putting XHTML in XML can be a relatively quick fix for a lot of problems.

Beyond the Browser and Within the Browser enabled its users to include XML content within its XML element type, making it possible for IBTWSH to both contain XML and be contained by an XML document.

Document Definition Markup Language (DDML – at http://www.w3.org/TR/NOTE-ddml ), a simple schema vocabulary, uses IBTWSH for human-readable documentation of schema components. The DTD fragment includes IBTWSH and employs it for the content model of the DDML:Doc element:

   <!ENTITY % ibtwsh SYSTEM  "http://www.ccil.org/~cowan/XML/ibtwsh.dtd">
   %ibtwsh;
   <!ELEMENT DDML:Doc  %struct.model;>
   <!ATTLIST DDML:Doc
   xmlns CDATA #FIXED  ""><!--IBTWSH has no namespace-->

The struct.model entity is much like the Block.mix entity in XHTML; it enables schema designers to add comprehensive comments to their schemas, not just a few sentences. Although DDML files aren't meant for presentation in a browser – they describe document structures, after all – the use of the HTML vocabulary makes it easy for schema creators to use a familiar vocabulary and familiar tools to describe the structures they create formally with the DDML schema vocabulary. Documentation creators can create transformations that turns the schema "inside out," building an HTML document describing the schema that uses the DDML:Doc elements as a foundation. Even without that extra step, developers may be able to open a DDML file in a browser and get a reasonable amount of information about the schema depending on how (and if) the schema creator uses the DDML:Doc element.

What HTML Has to Offer XML HTML provides a well-known vocabulary for which an amazing amount of infrastructure is already available. Browsers, widely available for free, are only the most visible aspects of that infrastructure. HTML editors are commodity tools, available in a range of prices and sophistication. Components for viewing HTML in programs are available in environments from Windows (where you can "borrow" Internet Explorer's HTML rendering DLL) to Java (where the Swing library includes a set of components for viewing and editing HTML) to much smaller, text-only environments. HTML has been thoroughly poked, explored, and criticized, leading to the development of best practices that can support information access for the disabled and the integration of complex information structures from a wide variety of sources. While HTML has its limits, and developers encounter those every day, XHTML seems to lead the path forward to using HTML vocabularies within XML documents, as well as using XML to enrich XML documents. You can work around XHTML's insistence on the default namespace, as you see in the next section. While many XML documents may be capable of getting along just fine without XHTML or the HTML vocabulary, the low cost of using HTML should make it an attractive option for many cases in which it can be useful.

As of this writing, the strengths of HTML are obvious. But the means of integrating that infrastructure with XML are not obvious. The current generation of HTML tools is designed to create HTML documents, not to create XML documents that may include some HTML. As a result, taking advantage of HTML within XML is difficult. However, this approach may be worth the trouble. At the same time, browsers remain very HTML-oriented, and no standard yet exists (XLink may come eventually) that lets XML do tasks that are very simple in HTML (such as the inclusion of images, scripts, and other components). So far, the browser vendors seem content to let XML documents access these facilities through the HTML vocabulary.

Applications for XHTML Islands While Microsoft is pushing XML data islands within HTML documents, let's explore how XHTML document islands can fit into an XML framework. We examine both XHTML 1.1-conformant approaches and the more informal set of rules supported by the early XML-aware browsers, trying to find a consistent means of using HTML vocabulary within XML documents that can work over the long run.

Note Within this section, you explore the implications of using the XHTML vocabulary within XML documents, not its impact on XML DTDs. The next section discusses the DTD issues for various types of XML development.

Images, scripts, and forms in browsers HTML provides a rich set of functionality that the XML specifications don't support yet. While any XML document can contain markup describing images, scripts, and forms, there are no standardized tools for notifying applications that this markup should be treated as images, scripts, or forms. Things that seem extremely easy in HTML can be very difficult in XML simply because applications arrive with very few assumptions about XML content. Cascading style sheets, originally built on top of HTML, didn't address these issues because HTML already did. As a result, there's no easy way to include such content in XML documents for display in today's Web browsers – unless you fall back on an HTML vocabulary. Namespaces ride to the rescue here (although with a few hitches). They enable XML document creators to identify some elements and their attributes as HTML. Those elements must use the HTML vocabulary – you can't rename an img element type image or picture – but this approach can solve some problems for XML developers targeting Web browsers. At present, the Web browsers (Netscape 6 preview release, Opera 4 beta, and Internet Explorer 5.x) use a namespace-based HTML 4.0 to identify HTML information within an XML document, not the namespaces defined in XHTML 1.0. The URI in use is: http://www.w3.org/TR/REC-html40 In most of the browsers, you can assign this URI to the default namespace or to a different prefix (typically html or xhtml). However, Microsoft Internet Explorer supports the exclusive use of html as the prefix (and regards all elements prefixed with html as HTML vocabulary even if they are assigned a different namespace).

Tip For more detailed information on using XML and CSS to create documents for Web browser presentation, see my series of articles at XML.com: http://www.xml.com/pub/au/St._Laurent_Simon. Let's start with a simple example that you can use for either browser display or machine-to-machine communication that provides some basic information about a article. It uses the HTML img element type to bring in a picture, a for a link, and h1 for a headline:

   <?xml  version="1.0"?>
   <?xml-stylesheet  type="text/css" href="articlestest.css"?>
   <catalog  xmlns:html="http://www.w3.org/TR/REC-html40" >
   <html:h1>An XML  Introduction</html:h1>
   <article><cover>
   <html:a  href="http://www.amazon.com/exec/obidos/ISBN=076453310X">
   <html:img  src="http://images.amazon.com/images/P/076453310X.01.MZZZZZZZ.gif"
   /></html:a></cover>
   <author>Simon  St.Laurent</author>
   <title> <html:a  href="http://www.amazon.com/exec/obidos/
   ISBN=076453310X/">XML: A  Primer, 2nd Ed.</html:a></title>
   <pubyear>1999</pubyear>
   <publisher>IDG Articles</publisher>
   <isbn>0-7645-3310-X</isbn>
   <price>$19.99</price>
   </article>
 </catalog>

You can display this XML document (which has no DTD whatsoever) very easily using the minimalist style sheet shown here:

   catalog {display:block; }
   article {display:block; padding:5px;  }
   article *{display:block;}
 

Caution The current release of Internet Explorer 5.0 for the Macintosh displays the link, but doesn't make it active. (The images work fine.) The browsers can render the XML portions of the document using the rules provided in the style sheet, and they can render the HTML portion using their built-in understanding of what the HTML vocabulary does. This isn't exactly XHTML – the namespace (and use of the prefix) is different, there is no DOCTYPE declaration, and no modules are included – but it's the likely path toward XHTML within browsers.

Caution Unless XHTML modularization changes to permit namespaces other than the default namespace to represent XHTML, the preceding example will never be valid XHTML. Making it valid requires the creation of a different namespace for the XML and a declaration making the XHTML namespace the default namespace. That will break Internet Explorer's current HTML-in-XML support, which depends on the html: prefix.