Re: error recovery

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".

Noah

Received on Monday, 20 February 2012 18:45:32 UTC