Re: XPath support for using multiple ixml implementations

Hello again,

Even if ambiguity is not always 'the same' given the universe of possible
algorithms - or especially - then it seems it is (a) often useful and (b)
sometimes critical to understand whatever ambiguity is there.

An 'ambiguity being there' is kind of like a 'dearth of bread in the
larder', in case anyone else remembers keynote address by CMSMcQ on topic
of RDF and semantic triples.

(So far at least two kinds of ambiguity have been mentioned plus two other
kinds, which might make four. I am told there are seven.)

This being said - I agree with Graydon - I wonder if it would be onerous to
require that any processor does what Norm's does, namely be able to say out
loud what it sees, in some appropriate form. (Not that this should be
default setting, only an available option.)

If that is onerous (even if sometimes) then I'm kind of thinking the less
said, the better, while Michael's and Norm's approach of making information
available -- and clear consequences, but not promises -- is the right one.
(But I doubt that can be usefully mandated.)

Cheers, Wendell


On Tue, Mar 3, 2026 at 1:35 PM Graydon Saunders <graydonish@fastmail.com>
wrote:

> 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...
>
>
>
>
>
>

-- 
...Wendell Piez... ...wendellpiez.com...
...pellucidliterature.org... ...pausepress.org... ...github.com/wendellpiez.
..