Re: XML namespaces on the Web

2009/11/17 Jirka Kosek <jirka@kosek.cz>:
> The question is whether there should be such unified error recovery for
> XML when it is supposed that XML should be well-formed and it should not
> be necessary to fix it. Having unified error recovery will be excuse for
> content producers and can lead to producing more and more
> non-well-formed content.

Why is that a bad thing, as long as handling remains well-defined and
relatively simple to implement?

> The similar situation is with web-browsers and HTML. HTML5 is just draft
> and its parsing algorithm is not yet widely deployed. Each browser thus
> uses its own error recovery mechanism -- of course they are quite
> aligned for many reasons, but not exactly same.

This is what we want to avoid for RSS/XHTML/etc.

> If you think that there
> should be unified error handling for XHTML content, solution is very
> simple -- just take respective parts from XML5 proposal and add them to
> HTML5 and say that if UA finds well-formdness error in XHTML content and
> it wants to recover from it it must use this specific recovery
> algorithm. And you are done and it is not necessary to change single
> character in the current XML spec.

XML5 doesn't necessarily need to be defined as a successor to XML.  It
could be a separate spec, maybe named something entirely different --
like XML Error Recovery.  A particular spec (like RSS or XHTML) might
mandate that UAs have to first apply XML Error Recovery to a document,
then parse it as XML.  (Or rather act as though they did this.  Of
course they'd probably do it in one pass in practice.)  An XML Error
Recovery spec doesn't belong in HTML5, because it's more general
(e.g., applying to RSS as well).

Does this sound good to you?  So no one would say a malformed document
is XML, but there would be an algorithm to make it into XML.

Received on Tuesday, 17 November 2009 21:10:56 UTC