Yet the biggest benefit to XHTML is that it makes it possible to target your data to any device whatsoever. Consider a news site such as CNN.COM. The site could conceivably (though they don't now) produce basic XML information consisting of news stories with specific key words denoted to add context to the information, perhaps coupled with multimedia such as audio files, transcriptions, video streams with SMIL-based timing to handle interactive charts rendered in SVG (Structured Vector Graphics), and dynamic links. The top stories are dispensed into an XML-formatted document that is used to retrieve salient information for teasers, coupled with a second XML document consisting of advertising media links that are keyed upon specific elements in the stories themselves (a fashion show might feature clothing and makeup advertisements, a football story would show beer, a terrorist incident with life insurance information, and so forth).
When you connect to CNN.COM, the server queries your browser and determines which modules of XHTML your client supports. Your Internet Explorer or Mozilla browser running on a high-end machine on a T3 might receive the full treatmentthe aggregate XML gets filtered through XSL to produce full multimedia streams which your client can then filter and display based upon its own built-in XSL transforms. The Palm Pilot gets XHTML Lite, given the relevant stories but with limited graphics (although perhaps with keys in the XHTML so that the parser can retrieve specific information from the stories itself for synopsis and later retrieval). The cell phone would get headlines, text, and basic links, but could be switched into audio mode (and output through your car's stereo system) so that the stories could be read by voice software, and could in turn send signals back based upon vocal commands (encoded in VoxML) to the server to change the story and retrieve the latest highway report.
This isn't a fantasy. All of the technologies described here are currently doable. Moreover, while it is certainly possible to build formatting software for either producing or extracting information from regular text streams (such as through ASP or JSP), such software has to be custom written for every format change, typically at incredible expense. With XHTML (and XML in general), you can specify the transforms that you want, and use them in highly modular fashions, designing only those pieces that affect a small piece of the stream.
You want to change the look of the site? Change the XSL filter. You want to target the latest holographic browser (okay, maybe there is a little fantasy here) with your server? Pull in the browser's XHTML extension from the manufacturer's Web site (if it's not already cached), use XSL to aggregate the profile elements into a schema, then use another XSL transform to output the results into 3DML (3-Dimensional Markup Language) with a side stream in XHTML for the attached 2D browser.
If you wanted to purchase the cool computer shown in the holographic viewer, your forms browser would in turn send back an envelope of form data to the CNN XML server, and convert it into an XML-based purchase order supported by the vendor of the product. The vendor, in turn, would send a payment request to your bank (which, in turn, sends more XHTML back to you to authenticate the purchase).
Put another way, the advantage to XHTML is that it becomes a part of the XML pipelinea fairly transparent part that does not need to be hand coded. Certainly it can bemuch of the Web is still made up of sites that are hand coded because they are expressions of art rather than commercebut XHTML will likely end up changing the way that most Web sites handle almost all of their output, and can free up people from the relatively mundane tasks of formatting content and move them into the more challenging roles of creating the content in the first place.