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

> 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