Agreed, XHTML as semantic is a relative term. However, I disagree that XHTML encourages separation of presentation from structure. I will instead claim that the W3C is pushing that separation using XHTML (among various other technologies), and XHTML makes it possible. However, making something possible is *not* the same thing as encouraging it. Speaking of the technology alone, rather than the W3C's position papers, the technology does not really make it any easier to write semantic XHTML+CSS than to write tag soup. Pre-CSS HTML does not make it possible at all. XHTML+CSS does, at least, make it possible. Availability of browsers that do not have presentation defaults for XHTML tags, but instead rely on CSS for *all* presentation, now THAT is encouragement. ;) Imagine a web browser that accepts XHTML, and effectively strips out all tags before presentation -- you are left with, visually, a plain text document. No presentation at all. If you attach a CSS stylesheet to the document, then and only then the browser presents it according to the CSS. At that point, you have XHTML markup that is structural. You have markup that provides semantic meaning, and nothing else. Now you are forced to examine the structure of the document, to see whether or not that structure is accurate and provides value. The presentation is a side issue -- how, given a particular class of user agent, shall I best present this document? is a question that is not relevant to the issue of how much value is imparted by a given type of markup. I believe that XHTML provides little added value as markup. Considered as an XML vocabulary, for purposes of structure, metadata and semantic meaning, XHTML provides little value. Hypertext links are useful. Meta tags are good, but other XML vocabularies better represent the same information. Likewise with the actual document structure -- I'd rather use a special-purpose XML vocabulary that better expresses the semantics of my individual document, if I'm going to the effort of adding semantic markup. Wouldn't you?
On the other hand, considered as the predominantly available means of presenting documents on the web, XHTML rawks. It's widely available, it looks good, there isn't a steep learning curve, and tools are widespread. Note the use of the word "presenting".
And that's my main point. XML either adds value to some degree, or it doesn't. If it adds value, I want to know in what context is that value added? In the case of XHTML, the context, 95+% of the time, is viewing the added presentation abilities, plus the value of working links. I don't get any value at all from the W3C's intent to saddle XHTML with some hand-waving semantic meaning. Alternative user agents do, and so I keep them in mind when I write HTML, and choose markup that works reasonably well for as many cases as I find reasonable for the personal effort.
And, when I can reasonably assume that the intended audience for my web-available documents use browsers that support CSS-styled arbitrary XML, or don't care about the presentation value in the first place (spiders and such), I will very happily switch over to XML, and take part in the semantic web.