Re: Error definition

Dave, I think what Michael might be getting at is this:

The spec isn’t involved with details of how an implementor communicates with a user. The spec isn’t concerned with details of how an implementor chooses to implement the grammar. The spec is only concerned with what a processor has to do in order to behave in a conformant way.

So, for example, Michael’s and Norm’s and Steven’s and Tom’s implementations will all differ in various ways. They’ll have different interfaces, different ways for users to specify input files, and so on. Users can expect them to produce the same result from a given input grammar and input string if they’re all conforming to the spec. But there’s no expectation that they’ll behave identically while producing that result, either behind the scenes or in communication with the user. 

Any implementation worth its bytes is going to have ways to communicate things like “your input string won’t parse against your grammar”, or “you’ve given me a directory name as an input, but I can only accept a filename”. But deciding the exact details of how and when to communicate those things is implementation-dependent because they don’t relate to the correct functioning of the language itself. 

Let’s say an ixml implementation allows you to specify multiple input files to the processor. You as the user might know quite well that only some files will match against the grammar, so you just need a note of which ones succeeded and which didn’t. It would make sense to report that some files didn’t produce output, without calling that an error and stopping the whole process. 

The point is, the ixml parser has completed its job successfully, regardless of whether it outputs vxml or not - because its job is to parse the input string against the input grammar and to output vxml *if a valid parse is found*. It would be in error if it a) failed to output vxml for a valid input string, or b) output vxml for an invalid input string. Tom would be daft not to communicate the matching and non-matching inputs to the user, but not because the non-matching inputs are in any sense “errors”. 

I don’t think Michael’s implying that implementors shouldn’t communicate clearly about whether the input string was valid against the input grammar; only that it isn’t an error of the ixml language if the input string isn’t valid against the grammar.


> 
> On 6 Feb 2022, at 14:55, Dave Pawson <dave.pawson@gmail.com> wrote:
> 
> On Sun, 6 Feb 2022 at 14:15, C. M. Sperberg-McQueen
> <cmsmcq@blackmesatech.com> wrote:
>> 
>> 
>> Dave Pawson writes:
>> 
>>> On Sat, 5 Feb 2022 at 17:26, C. M. Sperberg-McQueen
>>> <cmsmcq@blackmesatech.com> wrote:
>> 
>>> IMHO a bug in the processor does not give me 3, hence it is an error.
> 
>> On your view, in the situation you describe, who made the mistake? Who
>> committed the error? What rule did they violate?
> 
> The processor author. I then rely on them to inform the user that 'something
> went wrong'. Still an error ( in the users view). Why? Because I did
> not get output.xml
> 
> 
> 
> 
> 
>> If a processor fails to produce an XML parse tree for the input and
>> instead produces diagnostic information saying something like "this
>> input does not match the grammar; further details below ...", does that
>> suffice for your purposes?  Or is it necessary that the word "error" be
>> used in the message?
> 
> My view? It is an error.
> The input.txt file is 'in error'
> Hopefully the author of the processor will say @line 25 etc.
> 
> 
>> 
>> Is it necessary for your goals with respect to ixml that the spec use
>> the word "error" to describe the situation in which you do not get your
>> expected output?
> 
> My view? It would be helpful to an end user.
> Equally, classes of error (see XSLT rec) to assist debugging user code.
> 
> 
>> 
>> Do problems arise if the word "error" is not used in the spec when
>> describing that situation?
> 
> Problems of clarity?
> 
> 
> 
>>> Do you wish to build a playground for devs only?
>> 
>> Not particularly.  I would like a playground that is open to all and not
>> marked as closed off to me.
> 
> I would hope that your debug code is removed / not executing by
> the time the user has it?
> 
> 
> regards
> 
> -- 
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.

Received on Sunday, 6 February 2022 20:27:39 UTC