RE: [xml-dev] What is the rule for parsing XML in a namespace inside HTML?

["Joshua Allen" <joshuaa@microsoft.com>]

> I don't know, XHTML only starts to look iffy when considered in terms
of
> traditional browsers, 

I agree with this part.  I am just saying it is dumb to tell people to
use XHTML if they are only targeting traditional browsers, and we know
that the browsers and tool support is spotty.

> as fairly straightforward XML document markup it
> seems perfectly reasonable. Even with XML+XSLT+CSS we're dependent on

Now this I disagree with.  HTML is a mess.  Some tags are semantic, some
tags are presentation-only.  It is all jumbled together.  It's a very
poor vocabulary, and should be hidden from all but web page designers.
The actual data files should be written using a specific vocabulary with
well-defined vocabularies.

> The references to RSS are interesting,  it's rather like Len's case
> turned inside out - document islands in a data format.  But there the
> aggregator points to a completely different species of browser where
the
> data should (in principle at least) be XML. But content being
delivered

The key point is that the data is semantically well-defined.  Just
imagine if we had tried to build a universe of aggregators based on
screen-scraping XHTML rather than using moderately well-defined XML
vocabularies.  It would have been a disaster.  How can anyone say that
screen-scraping XHTML is a good idea??

> in syndicated feeds has to be interpreted somehow, and the options
> currently on the table are escaped HTML or nested/namespace-qualified
> XHTML. The former is a pretty awful approach when the latter is

That is a good point.  Storing presentation data as XHTML is not such a
terrible thing, but I still would prefer escaped HTML (because of tools
support).  But again, the point is that the machine-processable part
uses a well-defined XML vocabulary, and the presentation part is just an
embedded blob.  Mixing them is a terrible idea.