Re: issue #24 does an ixml processor have to match everything?

Lots of options? Perspective dependent?


Deserves time on the call IMHO

Regards

On Fri, 4 Feb 2022 at 14:56, Norm Tovey-Walsh <norm@saxonica.com> wrote:

> > OK, we differ on our understanding of 'error'.
> >  If the input isn't a sentence in the given grammar.
> > I understand that as an error.
> >   I'm curious why (if?) you don't?
>
> Sorry. I think we’re talking at slightly cross purposes.
>
> I agree that if you hand an ixml processor an ixml grammar and an input
> string, the processor should signal failure if the input string isn’t a
> sentence in the grammar.
>
> But at the same time, and thinking of the technical details more
> carefully, the parser is functioning perfectly normally and without any
> errors when it fails to find a parse. Failure to find a parse doesn’t
> mean that the processor has behaved incorrectly or in error.
>
> >> If a parser can determine that it will never succeed at some point
> >> before it’s consumed all of the input, then it can return a failure at
> >> that point. But that’s a quality of implementation concern, not a
> >> conformance one. It’s perfectly reasonable for the parser to consume all
> >> the input.
> >
> > A quality of implementation concern? Can we assume the author provided
> > a good implementation (otherwise thereby lays(lies?) madness?).
>
> Again, I fear we’re speaking of different things.
>
> If the input string isn’t a sentence in the grammar, the processor will
> fail to find a parse for it, and will/must signal that failure in some
> way. A user is very likely to consider that an error in the input string
> (or the grammar).
>
> I was speaking specifically of detecting this condition before the
> entire input has been consumed as a quality of implementation issue. I
> don’t think the specification needs to (or should) say that processors
> are required to recognize that the parse will fail before they’ve read
> the last character. Conversely, I don’t think it would make any sense
> for the specification to assert that processors must consume all of the
> input even if gauranteed failure has already been detected.
>
> (Depending on how inputs are passed to the processor, it may not even be
> possible to know how much of the input has been consumed. If the
> function is
>
>   Tree parse(Grammar g, String s)
>
> No one can tell how many characters in “s” were observed by the process.
>
> It just happens to be that my processor accepts a sequence of tokens,
> that don’t have to be single characters in the general case, and that it
> does so with a Java structure called an iterator, so in practice you
> *can* tell how much of the input I read by asking the iterator if
> there’s anything left after the parse.)
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norm Tovey-Walsh
> Saxonica
>
-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.