AW: QT4CG meeting 145 draft agenda, 9 December 2025

I sympathize with Alan’s suggestion.

As the current Generator proposal is (was?) based on an excellent XQuery implementation from Dimitre, my assumption is that it can already be used out of the box with existing XQuery 4.0 processors, by the inclusion of a simple "import module" statement in the query prolog. – Using it with XSLT or XPath-only implementations might be harder.

In principle, I agree with Norm that a custom implementation will always provide more freedom for optimizations. The question is whether our core language has serious restrictions that cannot be surpassed by an implementation in XQuery. Dimitre is certainly the one who can judge this best. If this should be the case, we could focus on these challenge instead (or first), before possibly incorporating the full function set.

Another solution could be to publish the Generator functions as a separate module, similar to the Binary and File Modules [1,2]. This way, we could target different deadlines for the finalization of the core specifications and for generators, and we could provide other data structures in the future in a similar way much more easily.

I am looking forward to today’s meeting.
– Christian

[1] https://qt4cg.org/specifications/expath-binary-40/Overview.html
[2] https://qt4cg.org/specifications/expath-file-40/Overview.html

________________________________
Von: Norm Tovey-Walsh <norm@saxonica.com>
Gesendet: Dienstag, 9. Dezember 2025 11:12
An: Alan Painter <alan.painter@gmail.com>
Cc: Liam R. E. Quin <liam@fromoldbooks.org>; public-xslt-40@w3.org <public-xslt-40@w3.org>; Dimitre Novatchev <dnovatchev@googlemail.com>
Betreff: Re: QT4CG meeting 145 draft agenda, 9 December 2025

> The argument for having generators as a separate library is that it can be a separate, parallel, somewhat independent initiative from QT4, hence a reduced effort for base QT4 functions and an even earlier QT4 release. As a fervent albeit non-practicing QT4 enthusiast, I would tend to vote for the separate library.

I think there are a few downsides to doing it in a library.

First, we abandoned any attempts to define a “module repository” system, so we don’t have an easy way for users to download and install modules.

Second, it might very well be the case that a library implementor might want to leverage BaseX features to improve performance, or Saxon features, or some other implementation’s features. That means multiple versions of the library or tedious complexity in it.

This is something like the argument that users can write these functions themselves if they need them. (Which obviates the need for someone who neither needs nor wants to understand them from having to be troubled by their presence in the spec.)

The counter argument that I found compelling to that approach is that the functions aren’t hard to write, but they’re a little bit subtle. Independent invention that gets the details wrong in slightly different ways is going to prohibit interoperability.

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica