- From: Dave Pawson <dave.pawson@gmail.com>
- Date: Sun, 6 Feb 2022 14:55:14 +0000
- To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
- Cc: Bethan Tovey-Walsh <accounts@bethan.wales>, Norm Tovey-Walsh <norm@saxonica.com>, ixml <public-ixml@w3.org>
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 14:55:39 UTC