Re: Error definition

Tomos Hillman writes:

> So if we have an input *i* and a grammar *g*, a potential error *e*
> and an output *o*:

> • If *i* is a sentence in the grammar *g*, you get *o* as expected
>   (xml nodes in whatever representation)

> • if there is a problem in *g*, potentially among other situations,
>   you get *e*

> • What should a parser return if everything works correctly, but *i*
>   is not a sentence in the grammar?  How does the parser say "sorry,
>   mate"?

For what it's worth, at the moment Aparecium returns an XML element of
the form

    <no-parse>
      <p>Sorry, no parse for this string and grammar.</p>
      ...
    </no-parse>

The ellipsis marks where Aparecium current dumps the data structures
most likely to be informative; using the data structures to construct
shorter and more useful messages to the user is on the list of things to
do later.

The element I return should probably be in the Aparecium namespace, and
there should definitely be an ixml:state="failed" attribute on the
no-parse element.

It is not clear to me at the moment whether some members of the group
will be happy with this because it clearly distinguishes the case where
the output is an XML representation of the input from the case where it
is not, or will be unhappy with it because it at no point uses the word
"error".

> Whilst I understand the distinction that Norm and Michael are making,
> I'm not sure how a processor should make that situation known to the
> user/calling function (along with any other information that would be
> useful downstream such as "I was expecting a ';'): throwing a
> catchable error seems a pragmatic solution...

In this case, a programming system's use of a term like "error" to mean
"exception" or "exceptional condition" seems sub-optimal, but, sure, if
you want to raise an exception that the user can catch, that seems
plausible.

What the spec says in its current form seems relatively clear:

    If the parse fails, some XML document must be produced with
    ixml:state="failed" on the document element. The document should
    provide helpful information about where and why it failed; it may be
    a partial parse tree that includes parts of the parse that
    succeeded.
    
I'll leave you to consider how to interpret that to make it compatible
with the raising of an exception.

Recall that this topic first arose when Dave asked (in [1])

    Parse to the end of the input string... unless errors are found? Is
    that a reasonable caveat?

and Norm responded (in [2]) with the suggestion that

    In parsers of the sort we’re using for ixml, not finding a match
    isn’t really an error, exactly. It just means your input isn’t a
    sentence in the grammar.

and (in [3]) Dave asked why Norm did not see it as an error.  That
question has, I think, now been answered several times, and the topic
seems to have shifted from an attempt to understand each other's usage
of terms to a discussion of what terms should be used in describing the
situation, and then from that to a discussion of whether the situation
is or is not ontologically speaking an error.

Agreeing on terms to use to make the distinctions that we need to make
in our discussions is useful; arguing about terms seems to me to be
useful only if it leads fairly rapidly to agreement.  Arguing about what
terms should be used in the spec without reference to any particular
passage of the spec or any proposal for changes to the spec seems to me
a sub-optimal use of our time.

Michael

[1] https://lists.w3.org/Archives/Public/public-ixml/2022Feb/0068.html
[2] https://lists.w3.org/Archives/Public/public-ixml/2022Feb/0069.html
[3] https://lists.w3.org/Archives/Public/public-ixml/2022Feb/0070.html

-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Monday, 7 February 2022 14:10:41 UTC