Re: XPath support for using multiple ixml implementations

There's a use case for ixml where you have some text in a larger document that might be a parsable thing (this p tag might contain a legislative history, a bibliographic citation, a postal address, etc.) where it's much simpler to maintain several grammars; one for each style of the parsable thing. (So a grammar for an MLA citation, a grammar for an APA citation, and so on.) Processing then tries the possible text against each grammar and compares the results to pick what it does with the results. ("not a citation", "APA citation", etc.)

So I can see an extension of that approach where you would want to switch parsers as well as grammars, but in principle you would only do that for implementation-specific behaviors or extensions and I think Norm's right that the specification shouldn't put itself in the position of requiring that those exist.

I do find myself thinking that there might be reasons to prefer one completely standard-compliant implementation over another in a dynamic way; different implementations can presumably lead to significant performance differences on input with specific characteristics. But that seems like something even further from something the specification should include.

-- Graydon

On Sat, Feb 28, 2026, at 12:13, Sheila Thomson wrote:
> > There’s nothing that says an implementation will always give the same parse every time
> 
> I hadn't realised that, thanks.
> 
> > Indeed. XML Calbash supports Markup Blitz and NineML because sometimes users want to switch between them.
> 
> David alerted me to this too. Even though I prefer to avoid proprietary features, that's my own self-imposed cross to bear! I think it's great that you've implemented this for others who would like the option. Thank you.
> 
> > I think that’s squarely a quality-of-implementation issue, not an Invisible XML specification issue
> 
> I did think twice before mailing this group because I concluded the same but I figured that *if* there is demand for such a feature it would likely surface in the ixml community first (and therefore might have been discussed already) before eventually being raised with implementers of the "outer" technologies and their relevant specs.
> 
> Thanks both (David and Norm) for responding.
> 
> Sheila
> 
> 
> On 28 February 2026 12:35:13 GMT, Norm Tovey-Walsh <norm@saxonica.com> wrote:
>> 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