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

Dave Pawson <dave.pawson@gmail.com> writes:
> Lots of options? Perspective dependent?
>
> Deserves time on the call IMHO

If that’s what the group wants to do, sure, but I don’t think there are
any issues here.

Michael reports that the CG discussed prefixes in April and decided not
to describe them in 1.0. Fine by me. It isn’t going to stop implementors
from doing it at user option[1] and if it turns out useful, we can
describe it formally in some later version. I don’t think anything about
1.0 as specified, or the semantics of the feature, will make it
difficult to add later.

As I’ve just replied in another message, I think the whole discussion of
“errors” has drifted into the weeds.

(I’m not suggesting that informal prose and user documentation won’t
have useful things to say about what users might sometimes wish to refer
to as errors, but there aren’t any spec issues here.)

                                        Be seeing you,
                                          norm

[1] One useful “prefix parsing” feature that I’ve implemented is an
option that let’s the user say “if the parse fails, but there was a
successful parse of a prefix, and the prefix consumed all of the input
except trailing whitespace, I just report a successful parse and ignore
the trailing whitespace.” I would *not* advocate that as a feature in
the ixml spec, but it’s still useful in an implementation.

--
Norm Tovey-Walsh
Saxonica