Re: XML namespaces on the Web

On Wed, Nov 18, 2009 at 10:13 AM, John Cowan <cowan@ccil.org> wrote:
> Shelley Powers scripsit:
>
>> As for the non-draconian bits...I've looked through the XML
>> specifications, but perhaps not as thoroughly as I could. Where is
>> there mention that error handling with XML must be draconian in
>> nature? I'm surprised at this, as normally W3C specifications are
>> rather dry, and the word "draconian" has so much flare to it.
>
> The word itself does not appear.  However, the XML 1.0 and 1.1 Recs
> define the notion of "fatal error", and say:
>
>    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).
>
> Specifically, it is a fatal error if the input does not match the
> BNF grammar, or violates one of the 12 well-formedness constraints.
> There are also 9 other fatal errors specified by XML 1.x, mostly having
> to do with bad encoding.
>
> In addition to the notion of "fatal error", there is also the notion of
> "error"; it is not easy to count the number of these.  The processing of
> a document with an error produces undefined results, which may include
> ignoring the error, reporting the error, reporting the error and aborting,
> or correcting the error.  All XML parsers that I know of treat all
> errors they detect as fatal.  (It is also possible for a parser to have
> "an error" in the sense of the Rec, which means that it's not a proper
> XML parser: the only error recovery is to fix the program(mer).)
>

Thank you for your answer, John. It's probably one of the best, and
most succinct, I've read on XML error handling.

I can understand the concept of fatal error, but draconian means
"extremely harsh and severe". I don't see that one needs to be
punitive when reporting an error, especially when parsing XHTML in a
browser.

Opera reports the error, but also provides very useful information
about the error. The application also provides the ability to re-parse
the page in more forgiving HTML. This is not draconian error handling.

Safari parses the page up to the point where the error occurs, and
then attempts to display what the page contents are up to the error
(to the best of its ability). It also provides a pink error message
highlighting where it first encountered error. Even with that ugly
pink, the result is not draconian.

Firefox hits an error, dumps this sickly yellow page with red writing
that pushes out to the right, making the response both punitive and
useless. Now, this is draconian error handling.

Dealing with a fatal error does not mean that the response has to be
draconian. In fact, the response should reflect the environment. In
the case of a web page, it would seem to me that Opera does the best
job of responding to the error while taking into account the
environment. Safari's response is also acceptable. Firefox's response
does not reflect any consideration for the environment, or any form of
concern about usability.

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.

> --
> John Cowan            http://www.ccil.org/~cowan     cowan@ccil.org
>                if if = then then then = else else else = if;
>

Shelley

Received on Wednesday, 18 November 2009 17:20:42 UTC