- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Sat, 28 Feb 2026 12:35:13 +0000
- To: Sheila Thomson <discuss@bluegumtree.com>
- Cc: public-ixml@w3.org
Sheila Thomson <discuss@bluegumtree.com> writes:
> My (non-markup geek) partner and I were just talking about how, when you have an ambiguous grammar, it's important to choose your iXML parser carefully and that the same parser might not be the best choice for all your ambiguous grammars.
Choosing a parser based on which result it gives you when dealing with an ambiguous parse is a risk I would be reluctant to take. There’s nothing that says an implementation will always give the same parse every time (Michael deliberately selected a random one), or that the parse selected won’t change on some version upgrade or if you change some option.
If it isn’t practical to eliminate the ambiguities, and you quite reasonably don’t want to use implementation-specific mechanisms for making explicit choices, I think a safer choice would be to do some preprocessing, with xsl:analyze-string say, before parsing to select units that won’t be ambiguous.
> Which led on to thinking about how, if you're calling iXML from within another tool or technology, such as an XML DB, XProc, or XSLT, you might need more than one iXML parser to be supported simultaneously.
Indeed. XML Calbash supports Markup Blitz and NineML because sometimes users want to switch between them.
> Is support for dynamic switching between iXML parsers a topic that's already been discussed?
I don’t think so. I think that’s squarely a quality-of-implementation issue, not an Invisible XML specification issue.
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Saturday, 28 February 2026 12:35:24 UTC