W3C home > Mailing lists > Public > public-appformats@w3.org > September 2006


From: Matthew Raymond <mattraymond@earthlink.net>
Date: Fri, 01 Sep 2006 15:19:34 -0400
Message-ID: <44F887C6.2010304@earthlink.net>
To: Henri Sivonen <hsivonen@iki.fi>
CC: public-appformats@w3.org

Henri Sivonen wrote:
> On Sep 1, 2006, at 16:40, Jim Ley wrote:
>> there is nothing in
>> the XML spec which requires that a application shows a _user_ an  
>> error,
>> rather than rendering something.
> The XML processor is required to stop normal processing and stop  
> passing data to the app in the usual way. It is pretty clear that the  
> intent of the spec is not to suppress errors silently. Rendering the  
> document up to the error is perfectly ok spec-wise.
> Are you suggesting that the XML processor continue processing and  
> passing bogus fixed-up data to the app but in an abnormal--yet  
> silent--way?

   Most browsers these days have a security bar or whatever it's called
that give you warnings, let's you know you're missing a plug-in and
whatnot. When processing XHTML via "text/html", the browser can render
up to the point of error, then the security bar would say something like

|                                                       +------------+
| An error was encountered while parsing this document. | View Error |
|                                                       +------------+

   Clicking on the "View Error" button would bring up a source code
dialog with the error highlighted or something like that.

   Not sure if it should switch to HTML rendering on an error, but the
browser user should definitely know that there was an error.
Received on Friday, 1 September 2006 19:20:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC