OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ Lists Home | Date Index | Thread Index ]
  • To: <danny@dannyayers.com>
  • Subject: RE: [xml-dev] What is the rule for parsing XML in a namespace inside HTML?
  • From: "Joshua Allen" <joshuaa@microsoft.com>
  • Date: Tue, 13 Jul 2004 10:44:54 -0700
  • Cc: "Bjoern Hoehrmann" <derhoermi@gmx.net>,<xml-dev@lists.xml.org>
  • Thread-index: AcRo+3XXfuktzzZdRc+EJVOnUZixkAABIFrQ
  • Thread-topic: [xml-dev] What is the rule for parsing XML in a namespace inside HTML?

> I don't know, XHTML only starts to look iffy when considered in terms
> 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
> data should (in principle at least) be XML. But content being

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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS