Re: XPath support for using multiple ixml implementations

> 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

Received on Tuesday, 3 March 2026 09:52:14 UTC