W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > June 2009

Re: Minutes for XML Core WG telcon of 2009 June 3

From: Simon Pieters <simonp@opera.com>
Date: Wed, 03 Jun 2009 21:42:38 +0200
To: "John Cowan" <cowan@ccil.org>
Cc: public-xml-core-wg@w3.org
Message-ID: <op.uuyrpcakidj3kv@simon-pieterss-macbook.local>
On Wed, 03 Jun 2009 20:20:24 +0200, John Cowan <cowan@ccil.org> wrote:

>> That's because if they don't, they are by definition not an XML  
>> processor.
> Almost.  If you read the definition, it's possible for an XML processor
> to report "unprocessed input" to its client after a fatal error.  It just
> so happens that nobody bothers.

Yeah. Some people take this and argue that it's allowed for the  
application to take the unprocessed input and continue to build on the  
parsed tree with error recovery. While this is technically not against the  
letter of the spec, it is black-box equivalent to a non-compliant "XML  
processor" that does error recovery.

>> There are user agents and libraries that process content that is labeled
>> as XML and do not abort upon errors, though.
> No spec can constrain the behavior of things that don't claim conformance
> to the spec (or claim it falsely).


>> I understand that this is the case as currently specified. I was just
>> trying to state my understanding of "HTML folks think the XML
>> spec is broken because it doesn't define error recovery".
> XML folks don't want error recovery.

I won't argue with that, but I stand by my statement that some folks want  
error recovery to the extent that they snip implementations with error  

You can define error recovery so that such implementations can  
interoperate with each other while stating that it is allowed to abort so  
that folks who don't want error recovery aren't forced to do it.

Simon Pieters
Opera Software
Received on Wednesday, 3 June 2009 19:43:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:40 UTC