Re: Error definition

I’m looking back at the latest version of the terminology document we tossed back and forth a week or two ago. In what I think is the latest version, we have:

 An *ixml grammar parser* is a special instance of an *ixml parser*, which takes as its   inputs the *ixml specification grammar* and an *ixml input string*. If it finds a    derivation for the input string, that string is a valid *ixml grammar*.
]
 An *ixml grammar* is any grammar for which a derivation is found by an *ixml grammar   parser*.

 An *ixml parser* is a parser which parses an *ixml input string* against an *ixml     grammar*. If it finds one or more derivation(s) for the input string, the parser outputs   a parse tree representing the derivation(s).

Given these definitions, “bad.ixml” is not, in fact, an “ixml grammar” if it cannot be recognized as a sentence of the ixml specification grammar.

Is it reasonable to apply the term “error” to an attempt to run an ixml processor with inputs which are not an “ixml grammar” and an “ixml input string”? 

(I now realise that I’m uncertain of the status of the terminology document; is it intended as part of the spec? Or is it just for the CG to keep track of the terms we’re using? If the latter, then of course these definitions aren’t terribly useful for defining errors in conformance.)

Apologies in advance if I’m being dense. It’s likely that I’m still misunderstanding some nuances of “error” and “failure” as terms of art. If anyone can point me at resources that will help me improve my understanding without requiring yet more patient explanations from my fellow CG members, I’d be very grateful.


___________________________________________________ 
Dr. Bethan Tovey-Walsh 
Myfyrwraig PhD | PhD Student CorCenCC 
Prifysgol Abertawe | Swansea University 
Croeso i chi ysgrifennu ataf yn y Gymraeg.

> On 5 Feb 2022, at 15:44, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
> 
> 
> Bethan Tovey-Walsh writes:
> 
>> Right, so “bad.ixml” should only cause an error if we’re providing it
>> as an input grammar and “something_else.ixml” as an input
>> string. ...
> 
> This way of putting it makes me a little nervous, since I think the
> question we are discussing is not how processors should behave but what
> words we use to describe how processors behave.  I agree with what you
> say if what you mean is
> 
>    so the term 'error' applies only when 'bad.ixml' is provided as
>    an input grammar and 'something_else.txt' as an input string
> 
> But even then I find I'm nervous, because I don't think we have yet
> reached a firm agreement on terminology.  Norm and I have explained why
> certain ways of using the word 'error' seem to us not completely apt,
> and you and Dave have explained why the term makes intuitive sense to
> someone who is trying to get a parse tree out.
> 
> I'm not now able to make a good suggestion for the best way to talk
> about parsing failures that are not conformance failures, but I think it
> would be good to try to find one.
> 
> As a stop-gap measure, it might help just to say that the words "error"
> and "failure" should normally be qualified:
> 
>  So 'bad.ixml' raises a parsing error when we parse it as an inut
>  string against the ixml specification grammar, and a conformance error
>  when we attempt to parse 'something-else.txt' against 'bad.ixml'.
> 
> Being willing to use the term "parsing error" in a situation where no
> one has made a mistake may be inconsistent.  But in discussions of
> parsing, situations in which the input is not a sentence are not
> infrequently described as errors, perhaps because the usual application
> area for parsers is in situations like compilers, where non-grammatical
> input can in fact be described as "in error" because the grammar has
> normative power. (And I admit it's not unnatural to think of grammars as
> providing normative rules, even when they are intended to be descriptive
> not prescriptive.  Is that just the memory of grade-school English
> class, or is it something deeper?)  The qualification may make the
> phrase a little less likely to be misunderstood as denoting a defect in
> the processor -- although in ordinary language "parsing error" could
> presumably refer to a mistake made by a parser, so there is still some
> scope for misunderstanding, and the longer I look at the phrase "parsing
> error" the less I like it.
> 
> Maybe we just need to say that any reference to 'error' in connection
> with input strings which are not sentences w.r.t. the input grammar
> denotes a failure of the input to match the grammar but not repeat not a
> failure of the grammar or the processor to conform to this spec.  For
> the reasons Norm and I have already laid out, that will make some of us
> uneasy.  But all we can do is try to define useful terms and use them in
> ways consistent with the definitions.
> 
> If anyone has a coherent suggestion, I'm all ears.
> 
> 
> Michael
> 
> 
> -- 
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> http://blackmesatech.com