- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Tue, 13 Jan 2026 19:03:41 -0800
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
- Message-ID: <CAK4KnZf0f+tkBWZZ=iccAgtYYRWE8eScKxvvKGv0Q2rGbjNcXA@mail.gmail.com>
Thank you, Norm, for taking the minutes!
> CG: " + ... We have concrete examples for the fn:generate function,
but we still don't have concrete examples for the generator
records."
I really don't understand this statement. We have 138 examples/tests.
Today's proposal had 5-6 examples, at least half of which deal with
integers (even / odd/, etc.
*Will N-way merge satisfy these people*? Here it is - and with really
deferred evaluation. Computation is done only on request, thus this works
beautifully with streams of data coming from external data providers.
Exactly as required for the news-aggregator use-case:
declare function gn:merge-sorted-generators($genOfGens as f:generator) as
f:generator
{
if(not(gn:some($genOfGens))) then gn:empty-generator()
else
let $minVal := min($genOfGens => gn:for-each(fn($gen){$gen =>
gn:value()}) => gn:to-array()),
$newGenOfGens := $genOfGens => gn:take-while(fn($gen){$gen =>
gn:value() ne $minVal})
=> gn:concat($genOfGens =>
gn:skip-while(fn($gen){$gen => gn:value() ne $minVal})
=> gn:skip(1)
),
$genTrimmed := $genOfGens => gn:first-where(fn($gen){$gen =>
gn:value() eq $minVal}) =>gn:skip(1),
$newGenOfGens := if(gn:some($genTrimmed)) then $newGenOfGens =>
gn:append($genTrimmed)
else $newGenOfGens,
$result := f:generator(initialized := true(), end-reached :=
false(),
get-current := fn($this as f:generator)
{$minVal},
move-next := fn($this as f:generator)
{gn:merge-sorted-generators($this?inputGens)}
) => map:put("inputGens", $newGenOfGens)
return
$result
};
And one test:
let $ar1 := [-100, -4, 1, 3, 5, 7, 9, 11],
$ar2 := [-100, -90, -80, -70, -60, -50],
$ar3 := [-10, -8, -6, -4, -2, 0, 15],
$gn1 := gn:make-generator-from-array($ar1),
$gn2 := gn:make-generator-from-array($ar2),
$gn3 := gn:make-generator-from-array($ar3),
$genOfGens := gn:make-generator-from-array([$gn1, $gn2, $gn3])
return
gn:merge-sorted-generators($genOfGens) => gn:to-array()
And the correct, wanted result:
[-100,-100,-90,-80,-70,-60,-50,-10,-8,-6,-4,-4,-2,0,1,3,5,7,9,11,15]
[image: image.png]
Thanks,
Dimitre.
On Tue, Jan 13, 2026 at 10:12 AM Norm Tovey-Walsh <norm@saxonica.com> wrote:
> 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
>
>
Attachments
- image/png attachment: image.png
Received on Wednesday, 14 January 2026 03:03:58 UTC