Re: New issue: error recovery practices (Re: Proposed TAG Finding: Internet Media Type registration, consistency of use)

On Wednesday, May 29, 2002, 1:39:53 AM, Tim wrote:

TB> I'm trying not to diss the issue that Rob's raising here.  Clearly the 
TB> decision as to how-liberal-to-be-in-what-you-accept is architectural in 
TB> scope.  On the other hand, the W3C specifies languages designed for 
TB> authorship by nontechnical humans, protocols for significant e-commerce 
TB> payloads, and pretty well everything in between, so is there an 
TB> architectural principle that cuts across the spectrum?

Good question.

TB>  For example, I
TB> (perhaps in a minority) am OK with HTML processors being very liberal in 
TB> what they accept; it helps let everyone publish to the web.

Hopefully you are in a minority there.

HTML processors being liberal in what they accept prevents reliable
and widespread DOM and CSS ever taking off on the client side because
who knows what the parse tree is; instead we get 'dynamic html" where
the script tests what browser and OS it is running on as the first
essential step abnd then deals with the few cases of browser and OS
that it knows about. As web access devices diversify, this is more and
more untenable. It simply does not scale.

This leads to the current tyranny of the legacy browsers which are
defined entirely by reverse engineering (and the XML community
contributes their support to this by "publishing to HTML" with XSLT)
such that the entirety of the Document Formats and Interaction domain
products are left out in the cold by the legacy browsers which
currently define the Web. Newer stuff (SVG browsers, SMIl players,
mobile devices that use an XML language that is not HTML) are the
only areas where there is hope. The rest has fossilized into a
non-architectural morass and is the single largest barrier to the
evolution and interoperability of the Web.

So no, it does not "let everyone publish to the web". It just costs
the development community zillions of dollars and hours of needless
wasted work in attempting to get something with minimal display
functionality on a handful of browser/OS combinations, screws everyone
else, is minimally accessible or internationalized and can't ever
change because of the risk of "breaking existing pages" (or "loosing
our current commercial grip due to the risks of interoperability and
commoditization of standards compliant alternatives" to take a more
Machiavellian view).

TB> I also believe that XML's draconian error-handling was the right
TB> design decision.

Of course. I just don't buy into keeping that advantage on the server.
Its just too useful to ignore. We need real XML clients, now.



-- 
 Chris                            mailto:chris@w3.org

Received on Wednesday, 29 May 2002 11:41:02 UTC