W3C home > Mailing lists > Public > public-xml-er@w3.org > February 2012

Re: error recovery

From: John Snelson <john.snelson@marklogic.com>
Date: Tue, 21 Feb 2012 11:05:39 +0000
Message-ID: <4F437A83.7040105@marklogic.com>
To: Noah Mendelsohn <nrm@arcanedomain.com>
CC: "public-xml-er@w3.org" <public-xml-er@w3.org>
On 20/02/12 18:45, Noah Mendelsohn wrote:
> On 2/20/2012 6:38 AM, John Snelson wrote:
>> I think we can easily say "a warning is reported", where the implementation
>> gets to define how a warning is reported. No API design needed here.
> Um, if you're not designing the API, how can you report the warning? I
> really think we should stick to making sure that interesting things about
> the parse can be easily discovered (e.g. that unquoted attribute values
> were parsed, and where), and we should stay far away from mandating what,
> if any, of that information should be reported as errors, warnings, through
> an API, in a console log or whatever.
> IMO, we want a technology that can be used in servers as well as clients,
> in interactive scenarious where a human is present and in others where
> operation is disconnected, and a very wide range of applications. Usually,
> when you design APIs or error/warning reporting rules, you tend to make
> limiting assumptions about the runtime context, the application and/or the
> programming languge being used. We don't need to "go there".

I think you and I are talking at cross purposes. At some level, we have 
to assume that there is an interface to an xml-er parse process (be it 
API, UI, etc.).

We don't need to get as concrete as specifying a Javascript interface. 
Instead, we can list our assumption that whatever interface the parser 
has, it includes some implementation-defined way to flag a warning. Thus 
the spec can say that "a warning is reported" in case X or Y, without 
being any more concrete about how that happens.

I think browsers may well implement that as writing to the console log 
if it's active, or to /dev/null otherwise.

The main point being: We're going to want to signal some non-fatal 
errors (warnings) in the spec. Doing so does not require any concrete 
API design.


John Snelson, Senior Engineer                  http://twitter.com/jpcs
MarkLogic Corporation                         http://www.marklogic.com
Received on Tuesday, 21 February 2012 11:06:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:47:26 UTC