- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 13 Jan 2026 18:12:34 +0000
- To: public-xslt-40@w3.org
Hello folks,
After a brief battle with GitHub infrastructure, we have draft minutes:
https://qt4cg.org/meeting/minutes/2026/01-13.html
QT4 CG Meeting 148 Minutes 2026-01-13
[1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
Pull Requests
Table of Contents
* [6]Draft Minutes
* [7]Summary of new and continuing actions [0/5]
* [8]1. Administrivia
+ [9]1.1. Roll call [12/14]
+ [10]1.2. Accept the agenda
+ [11]1.3. Approve minutes of the previous meeting
+ [12]1.4. Next meeting
+ [13]1.5. Review of open action items [2/5]
+ [14]1.6. Review of open pull requests and issues
o [15]1.6.1. Blocked
o [16]1.6.2. Merge without discussion
o [17]1.6.3. Close without action
* [18]2. Technical agenda
+ [19]2.1. PR #2350: 708 An alternative proposal for generators
+ [20]2.2. Issue #2351: Current Drafts: ...
+ [21]2.3. PR #2313: 2298 XQFO rules: definition of default
values
* [22]3. Any other business
Draft Minutes
Summary of new and continuing actions [0/5]
* [ ] QT4CG-143-02: MK to try to recover the ability to extract
formal equivalences into tests
* [ ] QT4CG-143-03: JK to look for C14N test suites.
* [ ] QT4CG-144-01: MK to consider if any now lost value comparisons
should be added as examples.
* [ ] QT4CG-148-01: NW to draft a PR that marks #2351 items as "at
risk" with appropriate definitions at the top of the document
* [ ] QT4CG-148-02: NW to publish a dated drafter after QT4CG-148-01
is complete.
* [ ] QT4CG-148-03: NW to revise his attempt at #2313 by using the
text "node" and a link to the appropriate text
1. Administrivia
1.1. Roll call [12/14]
Regrets: EP.
* [X] David J Birnbaum (DB)
* [X] Reece Dunn (RD)
* [ ] Sasha Frisov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [X] Dimitre Novatchev
* [X] Alan Painter (AP
* [X] Wendell Piez (WP)
* [ ] Ruvim Pinka (RP)
* [X] Liam Quin (LQ)
* [X] Norm Tovey-Walsh (NW) Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [23]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [24]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 20 January 2026.
JWL gives regrets for 20, 27 January.
1.5. Review of open action items [2/5]
* [ ] QT4CG-143-02: MK to try to recover the ability to extract
formal equivalences into tests
* [ ] QT4CG-143-03: JK to look for C14N test suites.
* [ ] QT4CG-144-01: MK to consider if any now lost value comparisons
should be added as examples.
* [X] QT4CG-147-01: MK to fix the change markup entry for
fn:curent-merge-group; it refers to the wrong function name.
* [X] QT4CG-147-02: NW to chase up DN and LQ about follow-up to the
generator discussion
1.6. Review of open pull requests and issues
This section summarizes all of the issues and pull requests that need
to be resolved before we can finish. See [25]Technical Agenda below for
the focus of this meeting.
1.6.1. Blocked
The following PRs are open but have merge conflicts or comments which
suggest they aren't ready for action.
* PR [26]#2345: 2299 Expand pipeline to allow arrow expression in
path expression
* PR [27]#2266: 540 system-property equivalent for XQuery
* PR [28]#2160: 2073 data model changes for JNodes and Sequences
* PR [29]#2124: 573 Functions to Construct Trees
* PR [30]#2071: 77c deep update
* PR [31]#2019: 1776: XSLT template rules for maps and array
1.6.2. Merge without discussion
The following PRs are editorial, small, or otherwise appeared to be
uncontroversial when the agenda was prepared. The chairs propose that
these can be merged without discussion. If you think discussion is
necessary, please say so.
* PR [32]#2377: 2195 F+O Editorial Corrections
* PR [33]#2375: 2195 Editorial Omnibus
* PR [34]#2371: 2369 Add content for F&O section 11 (Processing
binary values)
* PR [35]#2368: 2367 Misc XSLT editorial fixes
* PR [36]#2358: 2357 Standardize on element() rather than element(*)
Proposal: merge without discussion.
Accepted.
1.6.3. Close without action
It has been proposed that the following issues be closed without
action. If you think discussion is necessary, please say so.
* Issue [37]#1934: Supporting RELAX NG validation
* Issue [38]#1591: Implausible filter expressions
Proposal: close with no further action.
Accepted.
2. Technical agenda
2.1. PR #2350: 708 An alternative proposal for generators
See PR [39]#2350.
Thanks to DN and LQ for providing more use cases in email.
MK introduces his proposal.
* MK: I've used the phrase "incremental evaluation" for this topic; I
didn't want to use "lazy evaluation" because that's a broader
topic.
+ ... This is about functions and expressions that operate on a
sequence one item at a time.
* MK: It should work on sequences and arrays; I haven't done the work
on arrays yet.
* MK: I divided functions into categories based on whether they can
consume or produce infinite sequences.
* MK: We define a fn:generate function.
MK walks through the examples in the spec.
* JLO: Very interesting. This looks very promising because it's just
one function.
+ ... In the example with the random number generator, there's a
parenthesis missing in the funtion call.
* RD: When deciding whether functions can accept unbounded sequences,
are we going to try to do that with a set of properties?
* MK: Yes, I was thinking of doing it that way.
* DN: Thank you for this proposal. It's always good to have
alternatives. Our highest priority should be the user; more than
who makes the proposal, and more than what is convenient for the
implementors.
+ ... General impression is that this proposal is incomplete.
+ ... Conceptually it's fragmented and lacking a unifying
extraction.
+ ... Compared to original proposal, I think it's difficult to
understand
+ ... Forces sequence-valued yields to be encoded indirectly.
+ ... Lacks composibility
+ ... Lacks construction based on external providers
+ ... Too "implementation-defined"
+ ... In brief: it violates the principle of making things as
simple as possible, but no simpler.
DN goes into more detail about these points...
* DN: It doesn't define a formal evaluation model, composition rules,
external data integration, or observable semantics.
+ ... It's incomplete for a language-level abstraction.
* DN: The proposal mixes terminology, categores, gaurantees, advice,
core semantics, and warnings.
+ ... Hard to build a mental model, hard to reason
compositionally, hard to teach
* DN: Very difficult to understand compared to original.
+ ... The original proposal defines just one abstraction and
defines it fully. It shows you how everything builds on it.
+ ... The MK proposal shifts complexity from the implementor to
the user
* DN: Forces sequence-value yields to be encoded indirectly
+ ... The fn:generate() returns item()*
+ ... An item cannot be a sequence.
+ ... Theref ro eacy yield-value is only an item
+ ... There are work arounds: arrays, maps, etc. But these are
encodings not first class semantics.
* DN: Lacks composibility
+ ... In MK's proposal, composability depends on which functions
happen to be incrementally implemented
+ ... Gaurantees are selective and asymmetric
+ ... No type-level of semantic gurantee of streaming
composition
+ ... In the original proposal, every generator-consuming
function composes.
* DN: Lacks construction based on external providers
+ ... It's purely functional, it assumes internal state
progression, it cannot safely represent sockets, cursors,
feeds, backpressionr, etc.
* DN: Too implementation-defined / questionable portability
+ ... The proposal relyes on "may or may not",
"implementation-dependent", "not mandated", "outside the
scope"...
+ ... This is not acceptable for correctness, termination, and
resource safety.
* DN: Make it as simple as possible, but not simpler
+ ... That's not rhetoric, it's accurate.
+ ... the MK proposal removes abstraction, pushes complexity
onto users and implementations, leaves behavior unspecified.
* DN: The alternative proposal is incomplete and conceptually
fragmented
+ ... It's difficult to reason about. It lacks a unifying
abstraction, doesn't support external data providers, and
requires each yield-value to be a single XPath item.
+ ... It shifts complexity into user code.
* LQ: I understood the proposal much better after today's
presentation.
+ ... I don't think it's an either-or at this point; DN's
generators proposal is slightly higher-level, but could still
be built on this.
+ ... I don't think it's true that you can't have a function
that does external things. But you'd need room in the
generator record to have more space to hold things.
+ ... Bringing it into the language instead of having a separate
library is a great step forward, but the higher level stuff
needs a bit more work.
* JK: Thanks for the work everyone has put into this. For the PR on
the table now, it strikes me as falling into two parts: the
conceptual model of processing, that could be spun off profitably.
The second half is the generator itself, that struck me as a
somewhat trivial example. As a user, when I think about a
generator, my first thought is about the random number generator.
I've got a set of expectations based up on that, that there's a
next and stepping that I'm in control of. That's missing from the
fn:generator function. I don't find this proposal compelling.
* RD: One of the key advantages of this is that the result is an
XPath sequence, so you can do things like filter expressions, etc.
without any additional machinery. If you've got a function that
operates on a sequence, you can call it irrespective of whether the
sequence is a range or a generator.
+ ... Currently, if you're using the randon number generator and
you want to work out the average, you'd have to hand code
that. But you could leverage the existing function with
fn:generator.
+ ... Semantically, both of these proposals are in effect two
different views of the same concept. DN's is explicit exposing
an interator model whereas this proposal is wrapping that
machinery within the XPath semantics. I don't see the two as
being incompatible.
+ ... We could take DN's functions and use those to infer which
XPath functions are processable with a generator.
* DN: I have two more observations.
+ ... There's no formal equivalent for the fn:generate function,
but there are for the original proposal.
+ ... Saying you can't use distinct values with an infinite
sequence isn't quite right, you can ask for the first three
distinct values, for example.
+ ... I think the generator type is more expressive. The
move-next function for example is part of the state; it can
specify a different move-next function for the next generator.
+ ... Users want to be in control.
* CG: I agree with LQ, I think both the fn:generate function and the
generator record could both be interesting for users. I noticed
that fn:generate is easy to implement if your implementation
supports iterators. Our team found it intuitive, but the generator
record concept from before was much more difficult to understand.
+ ... Hakell has something called "unfold" that's similar to the
generator function. I see many simple use cases where this
function can be used, but with more complex scenarios you
might need generator records.
+ ... We have concrete examples for the fn:generate function,
but we still don't have concrete examples for the generator
records.
* JLO: I like the simplicity of fn:generate. I like the control that
a generator record would give us. I fear we'll end up in a swamp of
deciding how each function should behave.
* NW: Let's leave this for a week or two. We got some examples and
use cases in the last 24 hours or so. Let's see if we can have some
more discussion and make progress.
* DN: I provoded a few hundred tests, so I don't think it's more
work. It's all there and already working. We have to think about
users!
2.2. Issue #2351: Current Drafts: ...
See issue [40]#2351.
Last week, we discussed creating a dated, checkpoint draft. CG suggests
we review this issue first.
* NW: Are we ready to cut a dated release?
* CG: Are we going to cut some things? We should try to do that
before the draft.
+ ... The syntactic sugar for filtering maps and arrays
+ ... Functions related to maps and arrays.
* MK: Working groups sometimes mark features as "at risk" because the
WG expects them to change. We could try that.
* JWL: On the filtering, I thought the case for removing the
syntactic sugar was moderately strong. But it's not a hill I'm
going to die on.
* JLO: I'd propose that we mark the things that are stable.
* NW: I think that's too hard.
Some discussion seems to lead to consensus for marking the syntactic
sugar and the array functions as "at risk".
* JWL: If you're going to put at risk in, you'll need to mention it
right at the top.
ACTION QT4CG-148-01: NW to draft a PR that marks #2351 items as "at
risk" with appropriate definitions at the top of the document
Proposal: Take a dated draft at that point?
Accepted.
ACTION QT4CG-148-02: NW to publish a dated drafter after QT4CG-148-01
is complete.
2.3. PR #2313: 2298 XQFO rules: definition of default values
See PR [41]#2313.
* CG: I think it's a good solution for the first case, I'm not sure
about the second case.
* RD: In the grammar we have things that we put in comments: whether
it's whitespace signficant or not. Could we have a comment with a
note that points to the rule.
+ ... Just make the comment "note" that points to the rule.
* JWL: It was the "=" I didn't really like.
ACTION QT4CG-148-03: NW to revise his attempt at #2313 by using the
text "node" and a link to the appropriate text
3. Any other business
We've run out of time, we'll get an update from JLO about teaching XSLT
at the AS Commiunications Congress next week.
References
1. https://qt4cg.org/meeting/minutes/
2. https://qt4cg.org/
3. https://qt4cg.org/dashboard
4. https://github.com/qt4cg/qtspecs/issues
5. https://github.com/qt4cg/qtspecs/pulls
6. https://qt4cg.org/meeting/minutes/2026/01-13.html#minutes
7. https://qt4cg.org/meeting/minutes/2026/01-13.html#new-actions
8. https://qt4cg.org/meeting/minutes/2026/01-13.html#administrivia
9. https://qt4cg.org/meeting/minutes/2026/01-13.html#roll-call
10. https://qt4cg.org/meeting/minutes/2026/01-13.html#agenda
11. https://qt4cg.org/meeting/minutes/2026/01-13.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2026/01-13.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2026/01-13.html#open-actions
14. https://qt4cg.org/meeting/minutes/2026/01-13.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2026/01-13.html#blocked
16. https://qt4cg.org/meeting/minutes/2026/01-13.html#merge-without-discussion
17. https://qt4cg.org/meeting/minutes/2026/01-13.html#close-without-action
18. https://qt4cg.org/meeting/minutes/2026/01-13.html#technical-agenda
19. https://qt4cg.org/meeting/minutes/2026/01-13.html#pr-2350
20. https://qt4cg.org/meeting/minutes/2026/01-13.html#h-1970AB40-7A13-4A8C-848A-12C820BA0501
21. https://qt4cg.org/meeting/minutes/2026/01-13.html#pr-2313
22. https://qt4cg.org/meeting/minutes/2026/01-13.html#any-other-business
23. https://qt4cg.org/meeting/agenda/2026/01-13.html
24. https://qt4cg.org/meeting/minutes/2026/01-06.html
25. https://qt4cg.org/meeting/minutes/2026/01-13.html#technical-agenda
26. https://qt4cg.org/dashboard/#pr-2345
27. https://qt4cg.org/dashboard/#pr-2266
28. https://qt4cg.org/dashboard/#pr-2160
29. https://qt4cg.org/dashboard/#pr-2124
30. https://qt4cg.org/dashboard/#pr-2071
31. https://qt4cg.org/dashboard/#pr-2019
32. https://qt4cg.org/dashboard/#pr-2377
33. https://qt4cg.org/dashboard/#pr-2375
34. https://qt4cg.org/dashboard/#pr-2371
35. https://qt4cg.org/dashboard/#pr-2368
36. https://qt4cg.org/dashboard/#pr-2358
37. https://github.com/qt4cg/qtspecs/issues/1934
38. https://github.com/qt4cg/qtspecs/issues/1591
39. https://qt4cg.org/dashboard/#pr-2350
40. https://github.com/qt4cg/qtspecs/issues/2351
41. https://qt4cg.org/dashboard/#pr-2313
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 13 January 2026 18:12:41 UTC