Re: XPath support for using multiple ixml implementations

On Tue, Mar 3, 2026, at 11:27, Bethan Tovey-Walsh wrote:
> We don't currently mandate anything about showing more than one valid parse. A conforming processor need not allow the user to access parses other than the one it returns by default. (I don't much like this state of affairs. I've discussed previously why ambiguity may be a deliberate choice. I would like to be able to ask any processor for more than one valid parse of my input, but this is currently implementation-dependent behaviour.)

It is also the case that even where one wants to achieve an unambiguous parse, being able to see the ambiguous parses while you're constructing the grammar is extremely useful. Fully imagining what the grammar says and what the processor is doing is a rare skill.

I don't know if there's anything different about ambiguity which should go in the spec, but I think this kind of transitory utility of ambiguity during development ought to inform the understanding of the use cases.

-- Graydon

On Tue, Mar 3, 2026, at 11:27, Bethan Tovey-Walsh wrote:
> I don't *think* Norm is quite correct - I don't believe that the ambiguity of grammars is decideable, in the general case.
> 
> > Given what Norm says, the status quo might be adequate, at least if 'report but not stop' is a mandate in the sense that I have to *be able* to see ambiguities if I want. Alternative choices strike me as features, in that context, because I can always look.
> 
> 
> A conforming processor is not actually required to report that it has found ambiguity, though the spec states that processors *should* include an ixml:state="ambiguous" or somesuch on the output of an ambiguous parse.
> 
> We don't currently mandate anything about showing more than one valid parse. A conforming processor need not allow the user to access parses other than the one it returns by default. (I don't much like this state of affairs. I've discussed previously why ambiguity may be a deliberate choice. I would like to be able to ask any processor for more than one valid parse of my input, but this is currently implementation-dependent behaviour.)
> 
> BTW
> 
> 
> > On 3 Mar 2026, at 15:52, Wendell Piez <wapiez@wendellpiez.com> wrote:
> > 
> > Hello,
> > 
> > Given what Norm says, the status quo might be adequate, at least if 'report but not stop' is a mandate in the sense that I have to *be able* to see ambiguities if I want. Alternative choices strike me as features, in that context, because I can always look.
> > 
> > A formal ambiguity test also helps quite a bit. This means that developers can at least know when they enter those waters.
> > 
> > Testability (as I also just said) is probably the key question in my mind. :-)
> > 
> > Thanks again! Wendell
> > 
> > 
> > On Tue, Mar 3, 2026 at 10:47 AM Norm Tovey-Walsh <norm@saxonica.com> wrote:
> > Wendell Piez <wapiez@wendellpiez.com> writes:
> > > - A conformant processor must offer a mode to stop and report ambiguities instead of handling them
> > 
> > I don’t like it. Supporting ambiguity is a defining feature of iXML that makes it easier to use than other grammars (and better to the extent that easier to use makes something better).
> > 
> > > Maybe the mandated 'no ambiguities' mode would only have to report, not stop. But making it stop might be better.
> > 
> > Report but don’t stop is the status quo. The output tells you if it is one of a set of ambiguous results.
> > 
> > > If the spec is murkier, I would foresee a need for external tools to test for ambiguity. Is that formally possible?
> > 
> > Yes. NineML ships with a formal ambiguity analyzer:
> > 
> >   https://www.brics.dk/grammar/
> > 
> > It will tell you where either of two flavors of ambiguity (horizontal or vertical) occur in your grammar.
> > 
> >                                         Be seeing you,
> >                                           norm
> > 
> > --
> > Norm Tovey-Walsh
> > Saxonica
> > 
> > 
> > -- 
> > ...Wendell Piez... ...wendellpiez.com...
> > ...pellucidliterature.org... ...pausepress.org... ...github.com/wendellpiez...
> 
> 
> 
>