Re: XPath support for using multiple ixml implementations

> A conformant processor must offer a mode to stop and report ambiguities instead of handling them

In this sense, is a mode a property of the grammar or a consequence of the way in which the processor is invoked?

Sometimes the ambiguous parse is wanted; I would not like to see the spec make a decision that unambiguous parses are the more legitimate intent.

-- Graydon

On Tue, Mar 3, 2026, at 10:13, Wendell Piez wrote:
> Hello,
> 
> Bethan raises an important and sensitive question, not about ambiguities as such (or not only), but about 'conformance' and how its boundaries are to be defined.
> 
> IMV, the spec should say only
> 
> - A conformant processor must offer a mode to stop and report ambiguities instead of handling them
> - If such a mode is available, processors are free to offer any other modes and features, as features
> 
> Maybe the mandated 'no ambiguities' mode would only have to report, not stop. But making it stop might be better.
> 
> If the spec is murkier, I would foresee a need for external tools to test for ambiguity. Is that formally possible?
> 
> Interesting problem, thanks --
> Wendell
> 
> 
> 
> 
> On Tue, Mar 3, 2026 at 9:57 AM Bethan Tovey-Walsh <bytheway@linguacelta.com> wrote:
>> I am concerned that the spec's lack of rules about how the parse is chosen may be leading to confusion for users. It's particularly worrying if people believe that an implementation will always give them an expected result, since there's no requirement for that. The next iteration of MarkupBlitz or CoffeePot could, in theory, have changes to its algorithm which leads to a change in this behaviour, and this would still be fully conformant to the specification. If users rely on getting a particular parse from an ambiguous grammar, this may also lead to lock-in, which is a result we really should try to avoid if we can. 
>> 
>> I think we should discuss this problem and maybe throw around ideas about how to address it. It may be that there's no better approach than what we have now, but I do think it's at least worth a discussion. 
>> 
>> Potential approaches that come to mind immediately (I'm not saying any of these is necessarily good; I'm just trying to list things that would solve some part of the problem):
>> 
>> - require implementations to return a randomly chosen parse;
>> - require implementations to use a particular algorithm to choose the parse. 
>> 
>> Other possibilities?
>> 
>> BTW
>> 
>> ****************************************************
>> 
>> Dr. Bethan Tovey-Walsh
>> 
>> _linguacelta.com_
>> 
>> Golygydd | Editor geirfan.cymru
>> 
>> Croeso i chi ysgrifennu ataf yn y Gymraeg
>> 
>> 
>>> On 3 Mar 2026, at 13:12, Gunther Rademacher <grd@gmx.net> wrote:
>>> On 3/3/2026 10:52 AM, Norm Tovey-Walsh 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.
>>> 
>>> No, the behavior in Markup Blitz is neither “magic” nor purely arbitrary.
>>> 
>>> When Markup Blitz encounters an ambiguity, it maintains, for each alternative, a queue of deferred actions. An action in this sense is the completion of a terminal or nonterminal that will eventually be delivered into the parse tree. Among competing alternatives, Markup Blitz selects one with the smallest number of pending actions.
>>> 
>>> Operationally, this corresponds to choosing an alternative that requires the fewest derivation steps. In practice, this typically results in the most compact parse tree. I have found that this strategy aligns well with my own expectations, and my understanding is that others share this assessment.
>>> 
>>> For reference, the relevant code is here:
>>> https://github.com/GuntherRademacher/markup-blitz/blob/9481b2f295110174978796dbcaf33603a46f20a5/src/main/java/de/bottlecaps/markup/blitz/Parser.java#L730-L731
>>> 
>>> Best regards
>>> Gunther
>>> 
> 
> 
> --
> ...Wendell Piez... ...wendellpiez.com...
> ...pellucidliterature.org... ...pausepress.org... ...github.com/wendellpiez...