- From: John Snelson <john.snelson@marklogic.com>
- Date: Tue, 21 Feb 2012 11:05:39 +0000
- 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 -- John Snelson, Senior Engineer http://twitter.com/jpcs MarkLogic Corporation http://www.marklogic.com
Received on Tuesday, 21 February 2012 11:06:09 UTC