(unknown charset) Re: XML namespaces on the Web

On Wed, 18 Nov 2009 14:23:17 -0500, Liam Quin wrote:
> On Wed, Nov 18, 2009 at 10:31:23AM -0600, Shelley Powers wrote:
>> Perhaps rather than redefine XML, make it looser, we need to educate
>> browser developers about being aware of the user environment in which
>> they operate, and respond to errors accordingly.
> 
> +1
> 
> The biggest cutural difference I see, I think, is that for HTML,
> the Web browser is "do your best to display whatever was made"
> whereas for XML, it needs to be, "help the author to make a
> syntatically correct document".
> 
> I think I'd agree with those who say RSS isn't really a very
> typical XML format -- errors are so common that in a way it's
> closer to HTML.
> 
> Right now, apart from XHTML served as text/html, and RSS, most
> XML in the world is at least well-formed, because it needs to be,
> in order to work at all.  Overall, I think people in the XML community
> really want to keep it that way, too, and the "errors are fatal"
> policy is how that's accomplished.

Above you said +1 to "educate browser developers" to be less draconian. 
Here you say that the "XML community really want to keep it that way". 

John Cowan claimed there to be (I think) 22 fatal error categories in 
XML. And an not easy to count amount of -in theory- not fatal errors - 
which still, according to John, are treated as fatal errors in all 
known XML parsers. It is not clear to me how most in the XML community 
want to keep it - whether they want to keep all not fatal errors as 
fatal, or if they are open to discern between the kinds of errors.

One should think that A) browser vendors could have a look at the 
countless non-fatal errors an make sure that they are not treated as 
fatal. And B) that they could be Opera friendly instead of Firefox 
draconian w.r.t. fatal errors.
 
> The change to XML I've suggested for unobtrusive namespaces is not
> related to error handling.
-- 
leif halvard silli

Received on Thursday, 19 November 2009 10:38:47 UTC