- From: Dave Pawson <dave.pawson@gmail.com>
- Date: Mon, 7 Feb 2022 10:39:10 +0000
- To: Tomos Hillman <yamahito@gmail.com>
- Cc: Norm Tovey-Walsh <norm@saxonica.com>, "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Bethan Tovey-Walsh <accounts@bethan.wales>, ixml <public-ixml@w3.org>
On Mon, 7 Feb 2022 at 10:30, Tomos Hillman <yamahito@gmail.com> wrote: > > 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"? It says nothing. User error, go figure. Oh shit, I chose the wrong stylesheet (XSLT analogy). Or ... A smart impl, recognises that *most* good inputs should produce some output, issues a warning? "You sure these two matched?" IMHO the spec should try to provide errors as does XSLT. See Beths post? Every impl reports errors in its own sweet way? Therein lies madness?... More specifically, pissed off users. > > 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... If the processor does nothing with 50% of the input it may be as the user expected. Nothing to report. If the processor can spot something wrong, report an error|warning and say what you think is wrong? Error code E112: <standard text describing the error, plus any available information as to location> regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ.
Received on Monday, 7 February 2022 10:39:33 UTC