Re: XPath support for using multiple ixml implementations

Hello all,

I've been following along with the discussion on support for multiple implementations, and I find myself feeling that, while I can see that it may be desirable in the short term, it somehow just does not feel to me like it's the right way to be focussing on.

I find myself comparing the situation here of the relatively new ixml technology amidst a set of different implementations to the situation we had in the earlier years of html+css+js, where the various browsers had different implementations causing certain features to work in some browsers and other features in others - along with a handful of specific features to each browser. The idea of being able to call different ixml processors to render different parts of your input in implementation specific ways would have been like trying to get different browsers to render different bits of your html page in order to get "the best of all worlds".

I think we should be better concentrating on

- what are the differences that the specific implementations have
- why does one choose a specific implementation over another
- can the desirable specifics of a particular implementation be usefully formalised and brought/pulled into the ixml standard?



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.

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?

For example:

- enquire with Gunther what the logic of the disambiguation algorithm is that Markup Blitz uses?
- find a way to bring this into the formal specification of ixml
  - maybe as a disambiguation option?
- which can then be freely implemented by any implementation with a (future) ixml-standard

This seems to me to be killing two birds with one stone:

- working towards solving the disambiguation problem
- formalising the standard to reduce implementation differences and dependencies

Regards

Russell Watson

russell@mrwatson.de

P.S. Once again thanks for the great Symposium!


> On 3. Mar 2026, at 01:47, Bethan Tovey-Walsh <bytheway@linguacelta.com> wrote:
> 
>> I wasn't meaning that the iXML grammar should state what iXML parser to use.  I was thinking about how I might specify which iXML parser to use in my XSLT/XQuery/XProc application.
> 
> 
> Yes, exactly. It makes sense to specify a processor when it's being called, not in the grammar itself. 
> 
> BTW
> 
> 
> ****************************************************
> Dr. Bethan Tovey-Walsh
> linguacelta.com <http://linguacelta.com/>
> Golygydd | Editor geirfan.cymru <http://geirfan.cymru/>
> Croeso i chi ysgrifennu ataf yn y Gymraeg
> 
>> On 2 Mar 2026, at 23:56, Sheila Thomson <discuss@bluegumtree.com> wrote:
>> 
>> 
>> I wasn't meaning that the iXML grammar should state what iXML parser to use.  I was thinking about how I might specify which iXML parser to use in my XSLT/XQuery/XProc application.  At the moment, that's most commonly done outside of the code, when configuring the "outer" application (XSLT/XProc processor, XQuery DB) but usually the expectation seems to be that the same iXML processor will be used to apply all iXML grammars.  I was thinking of use-cases where more than one IXML grammar will be applied, each with different iXML parsers.  In XSLT and XQuery the iXML grammar will most likely be applied using fn:invisible-xml and in XProc it may be applied using fn:invisible-xml or p:invisible-xml.  In my use-case, the developer knows what iXML parsers are available in the run-time environment.  I was wondering about the viability of controlling that switch via an option in (fn|p):invisible-xml, passing in a URL (path/system ID/public ID) to the iXML parser, for example.  Alternatively, if you didn't know what iXML parsers were going to be available in the run-time environment, maybe something could be done to select them by iXML parsing algorithm... (a prioritised list) this is getting quite extreme now though! Especially as I'm not sure that all the iXML parsers share which algorithm(s) they use. Best to stick to examples where the run-time environment is a white-box.
>> 
>> Sheila
>> 
>> 
>> On 2 March 2026 21:54:43 GMT, Bethan Tovey-Walsh <bytheway@linguacelta.com> wrote:
>>> A grammar can't be forbidden from being used with any implementation, so it's difficult to imagine how a statement about which implementation you want to use would be meaningful. If I try to use a grammar with coffeepot, but it has a "...using MarkupBlitz" statement in it, how does that work? Does it fail? Is coffeepot expected to call MarkupBlitz? What happens if (gods forbid) MarkupBlitz ceases to exist?
>>> 
>>> BTW
>>> 
>>> ****************************************************
>>> Dr. Bethan Tovey-Walsh
>>> linguacelta.com <http://linguacelta.com/>
>>> Golygydd | Editor geirfan.cymru <http://geirfan.cymru/>
>>> Croeso i chi ysgrifennu ataf yn y Gymraeg
>>> 
>>>> On 2 Mar 2026, at 21:00, Graydon Saunders <graydonish@fastmail.com> wrote:
>>>> 
>>>> 
>>>> +include animal as muppet from "muppets.ixml"
>>>> from Norm's symposium presentation seems like it could extend.
>>>> +include animal as muppet from "muppets.ixml" using processor-name
>>>> seems like it could specify the processor or a preferred processor, while
>>>> +try animal as muppet from "muppets.ixml"
>>>> seems like it could specify the more detailed grammar to try for a specific non-terminal. Which means it doesn't show in the non-terminal in this grammar specifically but that also means there's one line to change.
>>>> 
>>>> On Mon, Mar 2, 2026, at 12:31, Norm Tovey-Walsh wrote:
>>>>> John Lumley <john@saxonica.com <mailto:john@saxonica.com>> writes:
>>>>> > I think Norm was considering a two stage match/parse process. Something like:
>>>>> >
>>>>> >  nonterminal: [L]+ {grammar: more-detailed-grammar.ixml <http://more-detailed-grammar.ixml/>}.
>>>>> >
>>>>> > where during the first pass nonterminal matches a string of letters (which will be retained as a text node below <nonterminal>, and then passing that input to parsing against more-detailed-grammar.ixml <http://more-detailed-grammar.ixml/> in a subsequent phase. It could of course nest.
>>>>> 
>>>>> Yes, though I’ve come no where near even imagining a plausible syntax for it yet.
>>>>> 
>>>>>                                         Be seeing you,
>>>>>                                           norm
>>>>> 
>>>>> --
>>>>> Norm Tovey-Walsh
>>>>> Saxonica
>>>>> 
>>>>> 
>>>>