Re: Use cases

>
> The scenario is that in the future, a vendor makes a tool that supports
> only text/html input and not application/xhtml+xml input, because the vendor
> doesn't care enough about XML. However, the user whose task is close enough
> to what the tool does has some non-XHTML XML (e.g. DocBook) content. The
> user wants to apply the tool to the XML content--i.e. in a way that the tool
> vendor didn't envision and develop for.
>
> (So basically this is about tricking developers of HTML-only tools into
> providing usefulness to users who have non-XHTML, non-SVG, non-MathML
> content even though the tool developer doesn't care enough about such usage
> to address it explicitly.)
>

Wasn't one of the key conditions on the HTML5/XHTML5 split the fact that
XHTML5 would be supported anywhere HTML5 would be? I may be wrong on this,
this was just my impression.

I'm trying to think of any use case where this scenario would hold true. XML
parsers exist on just about every platform and are readily available within
most programming environments, including JavaScript. It's very likely that
any tool that would work with a custom HTML5 parser would also be built to
consume XHTML and for the most part would probably prefer to do so as there
is no requirement for semantic interpretation. Server side process tool
vendors in general would likely PREFER to use XHTML in their workflows for
precisely that reason - they have existing tools for working with the XML
without requirement for semantic overlays, they can utilize them in
transformational workflows, and if they need to generate output to HTML5,
they can set that as a serialization at the endpoint of the transformation.
Simply because a couple of browser vendors thinks the world revolves around
HTML doesn't mean that the rest of the world does.

Kurt Cagle