Once upon a time there was HTML4 and a bunch of browsers implemented it reasonably well for quite a few years
HTML looks like XML, but it's not always/usually/ever compliant (which is OK because the browsers aren't fussy, accept pretty much anything and each make sense of it in different, weird and wonderful ways)
XHTML on the other hand *is* XML and depending on the mime-type, browser and direction of the wind will be parsed as such (or not!).
XHTML 2.0 was a wander off into the wilderness, shedding backwards compatibility and with it any chance of seeing daylight (it was recently taken out the back and shot by W3C after a few years withering away)
HTML5 is the next major release of HTML which introduces a bunch of interesting & useful features that push the boundaries even further, while remaining largely backwards compatible.
XHTML5 is pretty much just a strict XML rendering of HTML5.

That is, HTML4 ~= XHTML1, XHTML2 is dead and HTML5 ~= XHTML5. IMO (can't be too careful these days).

Remember XHTML is valid XML so it's a suitable candidate for APIs and indeed the demonstration API in the RESTful Web Services book uses it exclusively:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<head> <title>Planet List</title>

</head>

<body>

<li><a href="/Earth">Earth</a></li>

<li><a href="/Venus">Venus</a></li>

...

</ul>

</body>

</html>

Once you've parsed it you can easily extract the planet names with an expression like ul[class="planets"]/li/a/text() (granted XPath is not my area of expertise and there's a bunch of other ways to do it). Anyway the point is that this single (currently optional) rendering can be used for both humans and machines if we want.

While I am reasonably convinced that we want users to be able to access the API directly (it doesn't cost us anything to give implementors the option) I'm still not sold on the case for an XML rendering, especially when headers are better/faster/cheaper and require basically no parsing.

Anyway it's 4am already so I'll leave it at that for today...

HTML5 at Last Call

October 27th, 2009 by Ian Hickson

For a brief period today, there were no outstanding e-mails or bugs on the specs, and so I took that opportunity to transition us here at the WHATWG to the next stage of HTML5's development: Last Call! This affects three specs at the WHATWG:

There's also a version of the spec called Web Applications 1.0 (for nostalgic reasons) that has all of the above as well as a number of other specs, namely Web Storage, Web Database, Server-sent Events, and the Web Sockets API and protocol, all together in one document. With the exception of the Web Database spec, they're all now in last call at the WHATWG.

So if you've been waiting to see if someone else would report the problem that you had seen, well, if it's not fixed, they didn't! So you should now send that feedback in yourself.

There's two ways to send feedback. If your feedback is something short and simple, you can just load up the spec in your browser, click on the section with the problem, then type in your message using the review comments box that appears at the bottom of the window, and hit the "Submit Review Comments" button. This works for the HTML5 and Web Applications 1.0 specs. (Thanks to the W3C HTML Working Group for making their bug database available to us for this purpose.)

If your feedback is more elaborate, then you should subscribe to the mailing listand then send your feedback there.

Note: Lest there be any confusion, the W3C HTML WG has not yet transitioned HTML5 to Last Call at the W3C. HTML5 is a joint effort of W3C and WHATWG groups, but we have different issues lists and different criteria for going to Last Call. For more details on the W3C HTML WG's processes, see the W3C HTML WG charter.