Developing Web Applications Using XHTML: Problems and Benefits

Ian GRAHAM, Senior Manager, eSolutions Group, Emf!sys, Bank of Montreal
Email: <ian.graham@bmo.com> | <ian.graham@utoronto.ca>
Web: http://www.utoronto.ca/ian/
Presentation Notes: http://www.utoronto.ca/ian/talks/

1. Introduction
XHTML has been put forward as a powerful replacement to HTML that can migrate Web development to the more semantically powerful world of XML. Indeed this is both possible and useful, but doing so requires understanding the implications of XHTML on the current world of HTML, and in particular on the ways in which content is currently managed and assembled by content management systems, and processed by Web browsers. The purpose of this short paper is to examine these issues, and to look as the technical and process-management issues associated with integrating an XHTML-based approach into current Web environments.
The first issue to consider is how current browsers process XHTML data -- such data can in principle be delivered as either text/xml (XML data) or text/html (HTML data) MIME types. These issues are reviewed in the next section. The answer (it is probably not a surprise) is that current Web browsers can only reliably process data received under the text/html MIME type. This is important to know, as it has implications on how XHTML data must be processed before it is delivered to such browsers.
The second issue is how content management processes need to change to take advantage of the additional features of XHTML. This really touches on the management problem of converting a free-form HTML content management operation into one that supports the stricter world of XHTML. Section 3 reviews these issues, and suggests some strategies and technologies that may help.
Finally, Section 4 looks at approaches for dynamically generating well-formed XHTML for delivery to browsers. We briefly discuss XSLT-based approaches, and discuss some of the issues you need to account for to make XHTML content work properly when delivered under the text/html MIME type. We also discuss alternate strategies that may be worth considering.
Section 5 presents brief conclusions, while Section 6 provides some relevant references.
2. Browser Rendering of XHTML
A browser will process and display XHTML differently depending on the MIME type assigned to the data when it is sent to the browser. In practice, XHTML can be delivered using one of two MIME types:
•	XML data (i.e., MIME content type text/xml)
•	HTML data (i.e., MIME content type text/html)
Browsers that support both data types (Internet Explorer 5, Navigator 6, Opera 4) process the two types quite differently, using two different processing engines, or channels -- the main differences are summarized in Table 1. When XHTML content is delivered as HTML-type data, it is processed by the browser's HTML processor. In general, such processors do not understand XML mechanisms like internal DTD subsets, entity declarations, or CDATA sections, so that these features cannot be used in this case. Indeed, these features must be avoided for XHTML data being delivered via this channel, since most HTML processors mishandle these constructs, and render them incorrectly. 
Table 1. Main functional features distinguishing XHTML processing by a browsers HTML and XML "channels"
HTML channel	XML channel	
Large set of defined internal general entities for common non-ASCII characters and symbols	Only 5 XML-standard predefined general entities (lt, gt, amp,  apos, and quot)	
Default formatting properties for all standard HTML elements	No default formatting properties (exception: Mozilla)	
CSS support for id- and class-based CSS selectors (e.g., div.special,  pre#note) 	No support	
Hard-wired support for functional elements (links, replaced elements [img, object/applet], map etc.)	No support	
must be omitted -- only supports DOCTYPE declarations with no internal subset	Supports internal DTD subsets and arbitrary entity declarations, both internal and (sometimes) external 	
No DTD support	Supports DTD-based (and sometimes schema-based) validation 	
must be omitted	Supports CDATA sections 	
should be omitted to support legacy browsers	Supports an XML declaration	
No namespace support	Supports namespaces	
On the other hand, HTML processors support many "author-friendly" features, such as a large set of predefined general entities representing common characters, along with default formatting properties and functionality for HTML elements. This is why X/HTML data, sent via the HTML channel, is appropriately rendered complete with important functionality (working links, embedded images, image maps, applets, etc.). This of course reflects the roots of the HTML processors, where the design focus was on providing generic default rendering and functional properties for a simple, restricted language, at the expense of language extensibility.
Conversely, the XML channel employs a full-blown XML parser, which provides support for DTDs, CDATA sections and other data-centric useful features of XML. However, this channel does not assume any a-priori binding between the elements in the document and any rendering or functional properties for those elements. Indeed, the XML channel has no idea of how to render or process the elements in any document type, including XHTML. Thus, if you want to render XHTML data you must provide explicit style sheet rules specifying how that rendering is done. For XHTML, this means providing a default CSS "style sheet" to define default rendering properties for the various elements, plus additional resources (e.g., scripts) that "add-in" the specific functionality of common HTML elements (img, applet, anchors, style, script, link, etc.). 
Unfortunately, this is not yet easily possible, as browser technology is not yet sufficiently advanced to provide features for doing this. Internet Explorer bypasses this problem by letting the XML processor generate HTML content (either using scripts and the DOM interface, or using an XSLT style sheet), which is then directed to the HTML channel for rendering. Of course, the person authoring the XML content must also provide these scripts or style sheets -- and for XHTML content, this would seem a bit of overkill! The Mozilla/Netscape 6 browser takes a different tack, and uses the XHTML namespace declaration to bind HTML-like functionality (styling, image embedding, form, and anchor element functionality) to the elements defined in the XHTML name space. However, this binding is incomplete -- for example, link and style element functionality are not currently supported. Thus, even with Mozilla, it is difficult to achieve the same rendering and functionality available in the HTML channel.
As a result of these limitations it is almost impossible to write a single "XML channel" XHTML resource that functions properly across all XML-aware browsers.  This fact, combined with the fact that older browsers (Lynx 2.8, Netscape 4.x, Internet Explorer 4.x, Opera 3.x) cannot handle XML data at all, leads to the following conclusion:
•	For the foreseeable future, XHTML should be delivered to browsers as HTML data using the text/html MIME type.
2.1. Issues for XHTML delivered as HTML data
Given that XHTML data is being sent to an HTML processor, you need to make sure that the data is compatible with that processor. Some of the main issues -- namely omitting XML features not supported by the HTML processor -- were discussed in the previous section. But there are a few other points you in practice need to account for to ensure that the documents render correctly across all common browsers. 
For example, some older HTML processors have problems with XHTML empty-element tags (e.g., <hr/>) that do not have extra space characters between the trailing slash in the tag and any preceding text (element name or attribute value). Thus, you should be sure to write empty-element tags with extra space before the trailing slash, as in <hr /> or <hr size-"1" />. If you do so, then essentially essentially all browsers will properly handle the element. 
Also, some older HTML processors have difficulties with non-minimized attribute assignments (e.g., <hr noshade="noshade" /> as opposed to <hr noshade />). Table 2 lists the most common situations where browsers have problems with non-minimized forms. 
The next section summarizes some generic rules for generating XHTML data targeted at an HTML processor.
Rules for generating XHTML targeted at an HTML processor
1	Deliver the content as HTML (MIME content-type text/html).
2	Do not place an XML declaration at the start of the document (remove any that might be there).
3	Do not include an internal DTD subset. Use a DOCTYPE solely to define the dialect type of the document (e.g., 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > 
In the HTML channel, DOCTYPEs can control the rendering behavior of the browser (so called "DOCTYPE sniffing") as discussed in Section 2.2 
4	Do not use entity references other than the limited set defined in the XHTML specification. If the original XHTML data contains custom entity references, be sure to expand them before sending the data to a browser.
5	Do not use PIs (processing instructions): the probably won't hurt, but they are not understood by an HTML processor, and are useless to you. 
6	Do not use CDATA sections: most HTML processors will mishandle the content. Note that you must then be careful with CDATA sections used to enclose script or style sheet components (inside script or style elements)
7	In empty-element tags, add one or more characters between the trailing slash and any preceding text (element name or attribute value), as in <br /> or 
<hr size="1" />.
8	For compatibility with older HTML processors, specify hypertext element target names using both id and name attributes (e.g., <a name="foo" id="foo">. Older browsers (Navigator 4, Opera 3.x, Lynx) do not support id attributes for defining hyperlink targets.
9	Beware of possible problems with "non-minimized" forms of attribute value assignments, as described in Table 2.
Table 2. Table showing browser support for the "non-minimized" form for attribute values (e.g., nowrap="nowrap", as opposed to nowrap). 
Attribute	Valid on Elements:	Browser Support when Attribute Value is Provided	
		NN 3.x	NN 4.x	NN 5.x	IE 4.x	IE 5.x	OP 3.6x	LY 2.8.x	
nowrap 	td, th							n/a	
ism	img							 (sends no coordinate data to server)	
declare	object	n/s	n/s	?	n/s	?	n/s	n/s	
noshade	hr							n/a 	
checked	input						 (but  for radio buttons)		
disabled	button, input, optgroup, option, select, textarea	n/s	n/s				n/s		
readonly	textarea, input (text and password input only)	n/s	n/s				n/s	n/s	
multiple	select								
selected	option								
Noresize	frame							n/a 	
defer	script	n/s	n/s				n/s	n/s (no scripting support)	
The column "Valid on Elements:" lists the XHTML elements for which the attribute is valid. Here, the labels "NN" refers to Netscape Navigator, "IE" to Internet Explorer, "OP" to Opera and "LY" to Lynx. Checkmarks () and crosses () have the obvious meanings. A blank entry means that testing was not done, or was inconclusive. The string "n/s" means that the indicated browser does not support the attribute, in any form (with or without a value). The string "n/a" means that the attribute is not supported, but in this case because it is inapplicable to the specified browser (i.e., the browser does not support the rendering or functionality called for by the attribute). Table from The XHTML 1.0 Language and Design Sourcebook, by Ian S. Graham, John Wiley and Sons, 2000 (by permission of the author).
2.2. The HTML Channel and DOCTYPE Switching
With Internet Explorer 5 (Macintosh version only) and Mozilla/Netscape 6 (all platforms) you may also need to account for a useful albeit somewhat confusing feature called DOCTYPE switching. This mechanism is a workaround for the buggy support for CSS and for rendering of HTML data by the Netscape 4.x and Internet Explorer 4 (Macintosh) browsers. The browsers mentioned at the beginning of this paragraph implement CSS and rendering support correctly (well, for the most part anyway). However, this "correct" behavior can on occasion break the rendering of pages originally written to allow for the buggy behavior of previous browsers.  Thus, if you are working with HTML data that was designed to work with these older browsers, but has been converted to XHTML, you may need a way to recover the buggy behavior to get the desired rendering. 
As a result, the newer browsers support a special "quirks" mode that attempts to emulate the broken behavior of the older browsers. However, you then need a way of telling the browser which mode to use. These browsers use a mechanism called "DOCTYPE sniffing" -- the browsers read the string value of the DOCTYPE declaration and use this value to decide whether they should render a document using the "strict" standards-based mode, or a "quirky" rendering mode that reproduces typical rendering bugs.
Unfortunately, the two browsers interpret DOCTYPE string values differently, making it difficult to choose a value that is both a correct description of the DTD and that also triggers the desired "quirks" or "strict" mode. To help you choose an appropriate DOCTYPE that will do what you want on both browsers, Table 3 lists some that produce consistent "quirks" and "strict:" mode rendering on Mozilla/Netscape 6 and Internet Explorer (Macintosh).
Table 3. DOCTYPE values that yield "strict" standards-based or "quirks"-mode rendering. 
Strict, Standards-Compliant Rendering	
A DOCTYPE that claims a strict DTD. For example:
<!DOCTYPE html PUBLIC "-//W3C/DTD HTML 4.0//EN" >	(with or without a URI reference) 
<!DOCTYPE html PUBLIC "-//W3C/DTD HTML 4.01//EN" >	(with or without a URI reference)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" >
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" > 
	(i.e., any DOCTYPE containing the string XHTML)	

Quirky Rendering	
no DOCTYPE declaration (or an invalid one, or one from a 'standard' older than HTML 4.0)	
Choosing an appropriate DOCTYPE for served data can sometimes leads to a dilemma -- to ensure correct rendering, you may end up needing a DOCTYPE declaration that conflicts with the actual structure of your document! Fortunately the HTML processor doesn't actually use the DOCTYPE to validate the content -- it only uses this string to toggle specific behavior of the renderer. This is a particularly difficult thing for XML/SGML experts to accept -- that you may have to lie about the type of your HTML/XHTML document to obtain the desired rendering.
We will revisit this point in Section 2, when we discuss the ramifications of "upgrading" HTML content to XHTML.
Of course, the distinction between quirks and standards-based rendering applies only to data processed by the HTML processor -- all data processed as XML will (hopefully) be rendered according to a strict interpretation of the cascading style sheet (and/or XSL) specifications.
2.3. XHTML and Thin Client Browsers
A final consideration is the delivery of XHTML content to thin devices such as palm pilots, wireless phones, WebTV. Today these devices support their own particular subsets of "standard" HTML, in addition to proprietary language extensions (e.g., special formatting markup tags or entity references for specific icons). They do not support XML, but do support XHTML delivered to the devices as HTML data subject to the authoring constraints described earlier in this section and the restrictions on element support implied by the specific device.
One of the goals of the XHTML activity area is to define a "modularized" version of the XHTML specification. Modularization defines XHTML using a set of different logical markup modules that can be selected, and customized, to produce a "hybrid" XHTML document type that uses only those modules supported by a specific Web application. Thus, in principle, an application developer can use the modularization framework to define application-specific profiles of XHTML for use with different devices.
At present this is a moot point for browsers, since they neither support XML nor do they ever validate content. However, this issue will soon be important in a content management/generation environment, wherein different content can be generated depending on the targeted platform, and subject to the modules appropriate to that platform. We will touch on this subject in the next section of this paper.
2.4. XHTML and Improved Display Reliability
Given the above constraints it would seem that XHTML gives no pragmatic advantage over HTML -- so why should you bother using it? To the browser, the advantage lies in the well-formedness constraint of XHTML, which guarantees proper quoting of attribute values and the existence of end tags for all non-empty elements. Thus, if the delivered data is well-formed XHTML, then it will be correctly parsed by all HTML processors, and will produce "correct" rendering and functionality (i.e., correct hypertext links) consistent with the accuracy of the element nesting and attribute values. Of course, elements can be illegally nested (e.g., <td> table cell <tr> table row </tr> stuff </td>) and still well-formed, but at least this error will be handled similarly across all browsers, and thus hopefully easy to detect.
This is actually a big advantage over HTML, where the lack of such constraints often lead to difficult-to-spot rendering problems that affect only a small set of browsers -- typically the ones the content management staff don't have. XHTML can thus be helpful in ensuring more reliable, less buggy content.
Indeed, a rough analysis of many "broken" Web pages shows that a well-formedness constraint would eliminate approximately 50% of the rendering errors in downloaded Web pages. Thus, if your Web application uses human-authored tagged input as raw data for generating Web pages, passing that data through an XML parser, and verifying the well-formedness of the data, can save you an enormous amount of work. 
•	Well-formedness can eliminate more than 50% of common page rendering errors.
A second and arguably bigger advantage comes when managing content on the server, and in dynamically creating content for delivery over the Web.  We will examine these issues in Section 3.
2.5. Summary
For the foreseeable future, XHTML must be delivered to browsers under the text/html mime type. As a result, many XML features, such as internal DTD subsets, CDATA sections, and general entities, must be avoided in the delivered data. Then, to ensure correct processing by older browsers, care must be taken to add whitespace before the trailing slash in empty element tags. Also, some browsers will mishandle non-minimized attribute values, as outlined in Table 2. Finally, you may need to add a semi-arbitrary DTD (as outlined in Table 3) to ensure that the document uses the correct (strict or "quirky") rendering mode of the browser.
Conversely, XHTML content can be more consistent across various browsers, because the well-formedness constraint of XML ensures that an HTML processor will correctly parse the markup. Thus it is likely that using XHTML will reduce the number of "broken" pages viewed by your audience.
3. XHTML and Server-Side Data Management
The previous section discussed how today's browsers handle XHTML, and argued that one  real advantage in using XHTML lay in improved accuracy of the markup provided by XML's well-formedness constraint, even though the data ends up being processed by an HTML processor. 
At the server side, however, using XHTML can be very useful, as it lets you more rigorously control the quality and reliability of the data you manage, and more accurately dynamically assemble the data for delivery to a browser. 
These issues fall under the rubric of content management systems. In essence, content management/delivery systems they take data (typically from a database), insert it into a X/HTML template, and deliver the result to the user. This delivered content may be dynamically generated each time the user requests a resource, or it may be generated periodically and then cached on a server, but the process is basically the same. Of course, the advantage with the latter is that content-generation problems, once they occur, can be more easily detected and resolved.
The actual content "fragments" are sometimes machine-generated (for example from raw text strings stored in a database), but they are also often taken verbatim from human-edited plain text or XHTML input. Examples of the latter cases include user comments typed-in using a simple Web enabled editor, or news articles typed in by reporters, editors, or others actually working in support of a Web site. Indeed, many sites use a mixture all these approaches: different X/HTML page components are assembled on the fly from both, and the results are then inserted at appropriate places into the page template. 
Broken Fragments Can Yield Broken Content
The practical problem is that if any of the integrated parts are not well formed (e.g., missing a </i> or </tr> tag, or missing a quotation mark around an attribute value), then it is possible (and eventually, over enough examples, guaranteed) that the merged document will not render correctly. Thus, content can "break" unexpectedly, often leaving the content managers at a loss to figure out what went wrong. Indeed, as noted above, I have found that, in dynamically generated pages, approximately 50% of rendering errors are caused by errors in the snippets.
From a content management perspective, this translates into two issues: attempting to enforce well-formedness (and perhaps validity) of data that is added into your content repository, and ensuring that the system generates XHTML that can be accurately processed by a browser's HTML processor. We look at these two problems in the next two sections.

XHTML
fragment

XHTML
page
Template

XHTML
fragment

XHTML
fragment

XHTML 
to 
browser

Page generation engine 

Figure X1
The Web server engine dynamically merges the X/HTML template and multiple X/HTML "snippets" to produce the resultant document sent to the user. Markup errors in the snippets can lead to cascading rendering failures of the entire Web page. These problems can be limited if each snippet is well-formed.

3.1. Managing Data on the Backend
Obviously if you have a backend XML database and all content is entered using XML-aware tools, then you won't have a backend data management problem -- the data will always be well-formed XML, and will be straightforward to process given suitable XML tools. 
However, the real world doesn't work that way -- content often comes from non-XML aware tools, such as WYSIWYG HTML authoring packages or hand-edited content, and most of it is not well-formed. Also, a lot of content is provided as data fragments -- blocks of text (plus markup) that themselves may or may not be a well-formed, or may be valid only in certain contexts. A site management goal would then be to find ways to modify the ways in which data is entered into the system, so that new data is (at least) well-formed XHTML, and so that fragments can be reliably used within document templates to produce the desired XHTML result.
With hand-authored content this is made more difficult by the fact that human authors are likely unaware of the special features of XHTML, and its differences from HTML. And in truth they shouldn't have to know these things. Thus part of the goal is to make these changes without introducing any extra requirements to the job of entering content.
Hand-Authored XHTML Pages
We first look at the situation for users who are authoring complete documents. Of course, one way to ensure valid content is to mandate the use of validating XHTML editors. Full-featured XML editors, such as SoftQuad's XMetaL, Icon Information System's XML Spy, or Wattle Software's XMLwriter, do support DTD and/or Schema-based validation of XML, or can enforce authoring consistent with a DTD. Unfortunately, most of these tools are really targeted at structured markup applications, and do not integrate well into the WYSIWYG world (E.g., Netscape Composer, Microsoft FrontPage, Macromedia DreamWeaver) of most Web development operations.
There are also several popular Web page text editors that support XHTML syntax rules, although most do not enforce validity with respect to a DTD or Schema. Thus, although these tools can help in creating XHTML, it is important to verify the accuracy of the document before saving it your repository.  Several of these packages (some are listed in the References section at the end of the paper) include Dave Raggett's HTML Tidy tool, which can be used to check for syntax and well-formedness errors in the incoming data.
Editing Partial Content 
In many cases, human authors or editors do not writing full XHTML documents, and instead are preparing fragments-- for example, small news articles or "bulletin" announcements -- for use within page templates. In these cases the author typically uses a simple text editor to author the content, and often doesn't know much about HTML or XHTML: he or she simply knows the limited set of tags they need to prepare the snippet content. Indeed, content is often entered using a simple Web form, and submitted via a form to the server for storage and reuse. 
There are several strategies for XHTML-izing this process. For snippets authored with simple text editors, one option is to replace this editor by a simple validating XHTML editor, and to develop a stripped down DTD corresponding to desired snippet content rules. Appendix A shows an example of such a DTD, here corresponding to an XHTML div element that can contain only h3, h4, b, i, br, a, p, span, and img elements. Figure 2 shows such a snippet as edited by an alpha release of the new Architag Xray XML editor.

Figure X2
A snapshot of the Achitag Xray XML editor while editing an XHTML document snippet, subject to the DTD defined in Appendix A.. The shaded region below the edit window (at the top) displays the error messages from the XML parser. The content of this window is updated dynamically as the text is edited. The bottom window shows, in real time, the markup as rendered by a simple HTML viewer.

This editor (like some others) provides a minimal preview tool for viewing HTML output, so that the author can write text and view the results in the preview window. Unlike many other editors, this product lets you view the changes in real time as you are editing the file.
Processing Non-validated X/HTML Components
Of course, in many cases you can't easily modify an existing document management process to add new client tools such as validating editors. Certainly you can't do this for content being entered via a Web page. In these case your best bet is to pre-process content, and turn it into something that is well-formed before adding it to your data repository. Unfortunately I am not aware of any preprocessing tools that provide this functionality (although I am sure such a thing must exist). 
The process might be as follows:
1.	Take fragment
2.	Do a first pass correction on the content (e.g., convert element and attribute names to lowercase, add quotes around attribute values; strip disallowed tags)
3.	Check that the result is well-formed XML
4.	If it is well formed, save the data
4A.	If there are problems, either reject the data, or can pass it to someone for intervention.
Step 4A is somewhat easier if data is being entered in real time via the Web, as you can return the data (along with a description of the possible problems) to the author for correction. This does presuppose, however, that the author understands the problems and how to fix them.
Style Sheet and Script Content
Last, management of script and style components can be problem -- in general it is best, in an XHTML environment, to keep such content in external files referenced from the XHTML documents. This is because of the odd manner in which HTML processors handle the content of such elements. HTML processors look for CDATA element content -- or alternately for content inside a markup comment -- and send the unparsed content to the script or style sheet engine. If a script engine "writes" content back to the document (for example, using a document.write() method) this returned content replaces the script element in the tree, is then parsed in its place.
However, XML processors work quite differently. First, XML software can ignore or discard comments, so you can't place a script or style sheet inside a comment and count on it being preserved.  Second, the content of an XML element is always parsed before the content is processed. Thus, with an XML processor, the bare content of a script element will be parsed before the node content is sent to the script engine. 
For this reason, the XHTML specification recommends keeping script and style sheet content outside the documents themselves. However, if the content must be inside the document, then the specification recommends placing it inside a CDATA section. This keeps the content from being parsed (as if it were inside a comment), and also makes sure that the content is never (unlike comments) discarded. 
This is fine for storage of the data, and for delivery to XML processors. However, this will present problems to HTML processors, which do not understand CDATA sections. This must be done by hand with some XML tools, but is done automatically by XSLT processors. 
4. Assembling Dynamic XHTML Content
There are many ways to assemble dynamic XHTML content -- including all the tools (JSP, ASP, php, zope, ...) historically available for generating HTML. None of these tools, however, can guarantee valid and/or well-formed output. This is because the scripting environments are at present largely XML-unaware -- simple "scripted tags" in the documents are replaced by the generated script output, but the server-side dynamic processor is itself not required to produce well-formed tags as output.
XSLT, however, presents a newer framework that provides an improved model for dynamically generating XHTML content from XML (and XHTML) data archived on the server. Because of the way XSLT works, the transformation engine can guarantee (at least) well-formedness of the resulting output -- although this is admittedly no guarantee that the content will be valid or will work properly on a browser. Also, XSLT provides useful "switches" that can produce XHTML usable by HTML processors (for existing and legacy browsers) and XML processors (for next-generation technologies). Thus, this technology can hopefully be usefully repurposed as browsers migrate to better support for XML. 
There are some problems with this approach, however, and these can present substantial obstacles to implementing an XML/XHTML-based approach to an ongoing Web development operation. We will review these problems later in this section, and discuss some possible solutions to them.
4.1 The XSLT Output Generation Model
The XSLT development model is very similar to that shown in Figure 1 -- an XSLT processor reads in an XSLT "template" representing the desired output format (the "template" XHTML document) and also reads in XML "data" containing the data to be inserted into the XHTML template. The XSLT engine recursively processes the source XML "data" document, processing it according to the pattern matching rules and logic in the template, and copying appropriate nodes (template nodes plus transformed source nodes) into the results tree. And the result is (hopefully) the document you want to send to the browser -- at least it is if the template is written correctly, and if the XML "data" document contains the required data.
For example, a simple template document might look like the following:
<xsl:stylesheet 
       xmlns="http://www.w3.org/1999/xhtml"
       xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
       version="1.0" >

<xsl:output method="html" 
            encoding="UTF-8" 
            omit-xml-declaration="yes" 
            indent="yes" />

<xsl:template match="/">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>
      <xsl:apply-templates select="//x.title" /> </title>
..<link rel="stylesheet" href="style-main.css" />
</head>
<body> ...
... more template stuff .....
which copies the content of the source XML documents' x.title element into the XHTML title element (the copying rule appears later in the style sheet). Other rules would in turn copy appropriate fragments from the source document into the template.
Three special directives or features are noted here. First, the default namespace for this style sheet is declared to be xmlns="http://www.w3.org/1999/xhtml". This simply reminds us (and the style sheet processor) that the target namespace for output is the XHTML namespace. The other two output directives, method="html" and omit-xml-declaration="yes", help ensure that the pages are properly laid-out for use by an HTML processor. The former declaration, for example, makes sure that the style sheet processor does not "escape" <,  ,> and ampersand characters inside script or style elements.  Last, the omit-xml-declaration directive simply causes this part to be omitted at output -a special kindness to old browsers (e.g Navigator 3) which mistakenly render XML declarations.
4.1 Alternative Approaches: Web Macro Languages
XSLT is a powerful tool, but it also -- despite comments to the contrary -- often beyond the reach of many Web developers or designers. Moreover, the XSLT model, which for complex pages requires careful management and mixing, in the final results-generation template, of data and data processing -- is often inconsistent with the simple "plug and play" model of most current dynamic or database-driven Web sites. Indeed, the most common Web development model has Web designers using rich Web development tools to "graphically" flesh out page template designs, into which they then "plug" script components that magically insert the desired dynamic content.
In principle this could wed well with the XSLT approach, but in practice this marriage has not happened, and in fact may be difficult to accomplish. The problem is that XSLT is still largely a programmer's tool, and only accessible via a text editor. Most Web design, on the other hand, is done using graphical tools such as DreamWeaver. At present it does not seem obvious how to wed these two approaches together.
Separation of Roles and Responsibilities
One of the reasons for the success of the graphical "DreamWeaver" approach is the good separation of roles between the page designers and the software developers (who design the functionality that produces dynamic content for the pages).  The graphics team can happily produce mockups and designs for the developers while the developers create code to produce the scripted components: the designers can then simply edit their designs, insert the script hooks, and directly test the results.
A useful goal, then, would be to marry this approach to that of XSLT -- or to any other, more rigorous, XML-based model. One approach would be to make the page scripting environment XML-aware. This would let programmers develop code as outlined above, but the code could aware of the XML context in the document from which it is invoked, and could either produce content appropriate to that context, or else inform the developer (or graphics designer) of the error. 
The WebMacro approach (http://www.webmacro.org) would be one of many excellent starting places for an approach such as this. WebMacro is a servlet framework that simplifies servlet development by separating programming work from page design: With WebMacro, page designers create HTML templates containing WebMacro's scripts. Programmers work in clean Java code, free of HTML and other presentational clutter. 
5. Conclusions
An XHTML data model can provide much improved reliability for the data archived in a Web site, and in the data delivered as content to Web browsers. However, integrating this model into existing Web sites and content management systems requires some effort, although some simple tools (such as preprocessors and simple XML/XHTML editors) can help support "data entry" of well-formed XHTML.
Conversely, it is harder to upgrade existing content-management systems to support XHTML, since most do not have the built-in "smarts" to make this possible. Perhaps the best approach -- using XSLT to generate output -- is difficult to implement, because the processing model is often quite different from that understood by Web developers. However, next-generation tools should make this task easier, as should the embedding of XSLT-grade "programming" tools into existing dynamic page generation environments.
6. References
Quirks Mode and DOCTYPE Switching
http://www.oreillynet.com/lpt/a/163	IE 5 (Macintosh)
http://lists.w3.org/Archives/Public/www-validator/2000AprJun/0018.html
	IE 5 (Macintosh)
http://www.people.fas.harvard.edu/~dbaron/mozilla/modes	Mozilla/Navigator 6
http://www.people.fas.harvard.edu/~dbaron/mozilla/doctypes 	Mozilla/Navigator 6

Thin Client HTML
http://www.nttdocomo.com/i/index.html	i-Mode HTML
http://developer.webtv.net/ 	WebTV HTML
http://www.palmos.com/dev/tech/webclipping/tutorials/tutorial_web.html 
	Palm WebClipping HTML

XHTML 1.0, Basic XHTML, and XHTML Modularization Specifications
http://www.w3.org/TR/xhtml1/ 	XHTML 1.0
http://www.w3.org/TR/xhtml-basic/ 	Basic XHTML
http://www.w3.org/TR/xhtml-modularization/ 	XHTML modularization

HTML to XHTML Conversion Utilities
http://www.w3.org/People/Raggett/tidy/  	HTML Tidy
http://www.chami.com/html-kit/ 	HTML editor with HTML tidy integrated

XHTML-Aware Editors 
http://www.chami.com/html-kit/ 	Windows PC; integrated HTML-tidy
http://www.allaire.com/Products/HomeSite/	Windows PC; integrated HTML-tidy
http://www.barebones.com/products/bbedit.html	Macintosh; with syntax checker
All XML editors (e.g., XmetaL, XMLSpy ...)

XSLT 
http://www.w3.org/TR/xslt	Official specification
http://www.dpawson.co.uk/xsl/xslfaq.html	XSLT FAQ
http://www.cranesoftwrights.com/training/index.htm	Ken Holman's manuals
WebMacro and Velocity
http://www.webmacro.org 	WebMacro
http://wiki.webmacro.org/Velocity	Velocity

Some Books on XHTML
The XHTML 1.0 Language and Design Sourcebook, by Ian S. Graham, John Wiley and Sons, 2000 [The obligatory plug for my own book]
HTML and XHTML: The Definitive Guide, by Chuck Musciano and Bill Kennedy, O'Reilly and Associates, 2000
Beginning XHTML, by Frank Boumphrey et al., Wrox, 2000
Appendix A
The following DTD defines a simple div element content model suitable for authoring short article XHTML fragments.

Figure A.1. Simple div element content model suitable for authoring XHTML "articles"
<!--================ Character mnemonic entities  ======== --> 
<!ENTITY % HTMLlat1 PUBLIC
   "-//W3C//ENTITIES Latin 1 for XHTML//EN" "xhtml-lat1.ent">
%HTMLlat1;

<!ENTITY % HTMLsymbol PUBLIC
   "-//W3C//ENTITIES Symbols for XHTML//EN" "xhtml-symbol.ent">
%HTMLsymbol;

<!ENTITY % HTMLspecial PUBLIC
   "-//W3C//ENTITIES Special for XHTML//EN" "xhtml-special.ent">
%HTMLspecial;

<!--================== Imported Names ========== -->
<!ENTITY % Character "CDATA">
<!ENTITY % Number "CDATA">
<!ENTITY % URI "CDATA">
<!ENTITY % StyleSheet "CDATA">
<!ENTITY % Text "CDATA">
<!ENTITY % Length "CDATA">

<!--=================== Generic Attributes ========= --> 
<!ENTITY % coreattrs
 "id          ID             #IMPLIED
  class       CDATA          #IMPLIED
  style       %StyleSheet;   #IMPLIED
  title       %Text;         #IMPLIED"
  >

<!ENTITY % i18n
 "lang        CDATA  #FIXED 'en-us' 
  xml:lang    CDATA  #FIXED 'en-us'
  dir         (ltr|rtl) #FIXED 'ltr' "
  >

<!ENTITY % events "" >  <!-- No events allowed -->

<!ENTITY % focus
 "accesskey   %Character;    #IMPLIED
  tabindex    %Number;       #IMPLIED"
  >

<!ENTITY % attrs "%coreattrs; %i18n; %events;">
<!ENTITY % special "br | span | img  ">
<!ENTITY % fontstyle " i | b ">
<!ENTITY % inline "a | %special; | %fontstyle;  ">
<!ENTITY % Inline "(#PCDATA | %inline; )*">

<!ENTITY % heading "h3 | h4">
<!ENTITY % block "p | %heading; | div ">

<!ENTITY % Flow "(#PCDATA | %block; | %inline; )* ">

<!-- a elements use %Inline; excluding a -->
<!ENTITY % a.content "(#PCDATA | %special; | %fontstyle; )*">

<!ELEMENT div %Flow; >  <!-- generic language/style container -->
<!ATTLIST div
  %attrs;
  >

<!ELEMENT p %Inline;>
<!ATTLIST p
  %attrs;
  >

<!ELEMENT h3 %Inline;>
<!ATTLIST h3
   %attrs;
   >

<!ELEMENT h4 %Inline;>
<!ATTLIST h4
   %attrs;
   >

<!ELEMENT a %a.content;>
<!ATTLIST a
  %attrs;
  href        %URI;          #IMPLIED
  accesskey   %Character;    #IMPLIED
  tabindex    %Number;       #IMPLIED
  >

<!ELEMENT span %Inline;> <!-- generic language/style container -->
<!ATTLIST span
  %attrs;
  >

<!ELEMENT br EMPTY>   <!-- forced line break -->
<!ATTLIST br %coreattrs; >

<!ELEMENT i %Inline;>   <!-- italic font -->
<!ATTLIST i %attrs;>

<!ELEMENT b %Inline;>   <!-- bold font -->
<!ATTLIST b %attrs;>

<!--=================== Images  ============= -->

<!ELEMENT img EMPTY>
<!ATTLIST img
  %attrs;
  src         %URI;          #REQUIRED
  alt         %Text;         #REQUIRED
  longdesc    %URI;          #IMPLIED
  height      %Length;       #IMPLIED
  width       %Length;       #IMPLIED >