W3C home > Mailing lists > Public > www-archive@w3.org > December 2007

Re: XML processing Re: Dissatisfaction with HTML WG

From: James Graham <jg307@cam.ac.uk>
Date: Wed, 26 Dec 2007 20:15:35 +0000
Message-ID: <4772B667.9030207@cam.ac.uk>
To: Karl Dubost <karl@w3.org>
CC: www-archive <www-archive@w3.org>

Karl Dubost wrote:
> Le 25 déc. 2007 à 02:16, James Graham a écrit :
>> I don't believe it can; the fatal-exception-on-wellformedness-error 
>> behavior is likely to be unacceptable to any website that values its 
>> uptime.
> This is the current common agreement of people though the XML 
> specification, 3rd edition, says:
>     fatal error
>     [Definition: An error which a conforming XML processor
>     MUST detect and report to the application. After
>     encountering a fatal error, the processor MAY continue
>     processing the data to search for further errors and
>     MAY report such errors to the application. In order
>     to support correction of errors, the processor MAY make
>     unprocessed data from the document (with intermingled
>     character data and markup) available to the application.
>     Once a fatal error is detected, however, the processor
>     MUST NOT continue normal processing (i.e., it MUST NOT
>     continue to pass character data and information about
>     the document's logical structure to the application in
>     the normal way).]
> If we make a distinction between XML Processor and Application (for 
> example, browser)
> One possible interpretation (my own that will get me burned by XML 
> advocates.)
> A non well-formed document is sent to an application with an XML 
> processor.
> 1. The XML processor detects that the document is not well-formed and 
> report it to the application.
> 2. The XML processor continue the processing of data and report data 
> and errors to the application.
> 3. The XML processor has given back a stream with identified broken 
> information to the application
> 4. The application applies an XML recovery mechanism on the stream 
> sent by the XML processor and do what it wants with it such as 
> displaying the document if necessary.

Sure; I am aware of that interpretation of the spec and rather like it. 
However as you note it is not XML 1.0 canon that error recovery should 
occur and, worse, (as far as I know) no-one has written a spec for the 
kind of error recovery that could be performed by web browsers on 
general XML 1.0+XML Namespaces documents. Therefore if browsers were to 
implement the above we would be back to a situation where the error 
handing of each would have to be reverse engineered.

Taking all of this ino consideration, I can revise my statement that XML 
2.0 is needed for XML-on-the-web to "XML 2.0 with optional graceful 
error recovery, or XML 1.0 plus a specification for error recovery 
appropriate to human-targeted content" is needed for XML on the web to 
take off.
Received on Wednesday, 26 December 2007 20:15:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:17 UTC