[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: What is the rule for parsing XML in a namespace inside HTM

• To: <danny@d...>
• Subject: RE: What is the rule for parsing XML in a namespace inside HTML?
• From: "Joshua Allen" <joshuaa@m...>
• Date: Tue, 13 Jul 2004 10:44:54 -0700
• Cc: "Bjoern Hoehrmann" <derhoermi@g...>,<xml-dev@l...>
• Thread-index: AcRo+3XXfuktzzZdRc+EJVOnUZixkAABIFrQ
• Thread-topic: 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
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.

• Follow-Ups:
  • Re: What is the rule for parsing XML in a namespace insideHTML?
    • From: Danny Ayers <danny666@v...>

• Prev by Date: RE: Edi complexity, does ebxml really reduce it?
• Next by Date: Re: What is the rule for parsing XML in a namespace inside HTML?
• Previous by thread: Re: What is the rule for parsing XML in a namespace inside HTML?
• Next by thread: Re: What is the rule for parsing XML in a namespace insideHTML?
• Index(es):
  • Date
  • Thread