Re: XPath support for using multiple ixml implementations

If Nineml indeed chooses the "first" matching alternative factor in the
rule, which seems to be what I'm seeing for 'ajp', then it effectively
produces the same choice as would a PEG (parsing expression grammar)
parser. This might be a good default. At any rate, it works well for my
usage. But I suppose that I can look into adding disambiguation information
in the form of xpath rules.

On Tue, Mar 3, 2026, 10:52 Norm Tovey-Walsh <norm@saxonica.com> wrote:

> > From Sheila's presentation what I understood about the differences
> between the implementations is that, above all, Gunther Rademacher's Markup
> Blitz seems to have implemented some 'magic' disambiguation logic, which
> produces desirable (and in some way expected) results.
>
> No, I don’t think that’s what’s happening. Given an ambiguous parse, the
> processor has to pick one. It just happens that Markup Blitz and NineML
> choose different parses and, for Sheila’s application, the arbitrary choice
> that Markup Blitz made worked better than the arbitrary choice NineML made.
>
> NineML is capable of enumerating the parses and I think it returns “the
> first one” if you leave it to choose an arbitary parse. I’m tempted to take
> a page from Michael’s book and choose a random one.
>
> NineML has a number of features that allow you to influence the choice,
> but none are standard yet. (I implemented them in part so that users could
> try them out and give us feedback about how useful they are.)
>
> > Rather than going the (seemingly complex and potentially fragile) way of
> being able to switch implementations, would it not be a better way forward
> to bring these differences into the ixml standard?
>
> Remember that these differences only occur when the grammar is ambiguous.
> For unambiguous grammars, all parsers produce the same result.
>
> Allowing ambiguity is one of iXML’s most beneficial features.
>
> But, for an ambiguous parse, all of the different parses are *equally
> correct*.
>
> A grammar technology that doesn’t allow ambiguity puts a significant
> burden on the author: the author *must* make the grammar unambiguous. That
> requires a lot of skill and experience. It can be *hard*.
>
> Ambiguity is a feature, not a bug.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norm Tovey-Walsh
> Saxonica
>
>