QT4 CG Meeting 185 Minutes 2026-10-20

Regrets: JLO, JK

• [X] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [ ] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [ ] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [X] Wendell Piez (WP)
• [X] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW) Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 27 October.

Norm gives regrets.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-167-07: NW to review tests for interpolated strings with edge cases in mind
• [ ] QT4CG-170-01: RD to draft a proposal that attempts to address the lexical issues differently.
• [ ] QT4CG-177-01: NW to put the progress graphs back in the minutes.
• [ ] QT4CG-182-01: NW to review CG’s diff script

This section summarizes all of the issues and pull requests that need to be resolved before we can finish. See Technical Agenda below for the focus of this meeting.

See Issue #2914

• RD: How should we resolve the issues that MK raised?
  • … I propose that we should define an xs:codepoint on top of non-negative integers.
  • … Then we could update F&O to use that.
• RD: MK raised the issue that although XQuery and the Data Model define some types, those were done in agreement with the XML Schema WG
  • … The lexical space could change but I think that issue will arise no matter what because codepoints to string will raise an exception if the lexical space changes.
  • … That’s also true of the string type.
• MK: The namespace issue is a pesky formality, but not one we can ignore.
  • … My main comment is that the cost is out of proportion to the benefit
  • … It’s not all that useful, and invites speculation about why there aren’t also data types for other semantic concepts.
  • … Adding a new datatype across all the specs and implementations is expensive and doesn’t seem justified here.
• RD: One of the benefits is that it makes it clearer to a user reading the specs what the types are and what expected values they have. The current xs:integer isn’t ideal for code points.
• JWL: Echo MK’s thoughts. If we start adding this, we have to make sure that we define operations (like comparisons and arithmetic). I expect it’s an enormous amount of work.
• RD: I don’t think that’s an issue because I’ve proposed that it should be a restriction on non-negative integer, so all of the operations on numerics apply.
• JWL: But for example, suppose you permit addition of an integer onto a codepoint, now you have to ask if the result is still a codepoint.
• RD: We don’t specify the behavior of non-negative integer except for defining the lexical space.
• CG: I think another implication is that we also have the notion of permitted characters; it could still be that we’d reject inputs that are codepoints if they’re not permitted characters.
• NW: I don’t think we’re going to get consensus on this.

Proposal: Close this issue with no further action.

Accepted.

See PR #2350

• MK: This is a new function but also some explanatory text that might be interesting with or without the function.

MK walks through the explanatory text in the PR and the fn:generate function.

• MK: There may be errors in the proposed formal equivalence.
• AP: DN used the term “deferred evaluation”. With respect to “lazy” or “incremental”…
• MK: I don’t like the time-based notion.
• CG: I think we could make life easier if we dropped some of the introductory material about implementations and optimizations.
  • … Saying a function must be evaluated incrementally don’t make sense if you evaluate the whole sequence at compile time.
  • … The function itself is simple, so maybe…
• MK: I guess some of that could go. It was motivated in part by DN’s proposal.
  • … Might be best to leave all that out.
• RD: I like the proposal. It matches my thinking on this; it’s also similar to this feature in other languages like Kotlin.
• MK: Inside Saxon we have a similar function internally.
• RD: It’s a useful paradigm in languages that support sequences.

General agreement to accept the PR.

MK will make editorial revisions and then we’ll put it on the merge-without-discussion list for next week.

See PR #2881

• CG: We’ve had a look at this twice. I’ve made some minor revisions.
  • … We have one function fn:update that does a lot of things. But it isn’t a real replacement for the XQuery Update specification.
  • … You can do quite a lot with it as well.
• CG: I’ve tried to rewrite the rules to make them easier to understand.

CG walks through the examples.

• MK: Obviously, this is immensely powerful. My main concern is that there’s too much magic in how the value returned by the function determines what happens in the replacement.
  • … Instead of returning a simple value, return a record that includes an action plus a value.
  • … I think that would make it more explicit what kind of action you expect.
• CG: One challenge here is to make it work for maps and arrays and XML.
  • … It’s not quite clear what “insert into” and “insert after” mean in each cases.
• WP: Thanks for all of the hard work. The part that concerns me is, how much testing has this had in, for example, the XSLT context.
  • … What happens in the corner cases in XML for example.
  • … It seems that either this is pretty innocuous and I want it, or it’s dangerous and we should avoid it in XSLT.
  • … I’m concerned about the blurring of the boundaries. We need more use cases and demonstrations of the utility.
• CG: Those are good points. I haven’t given a lot of thought to XSLT.
• MK: One comment, I’ve been doing a lot of work on recursive descent transformation for arrays and maps. I’m not at all convinced that that approach can be optimized in the way this function could be optimized.
  • … This function might allow us to do in constant time what would other be linear.
• RD: I think it will be useful for XQuery code because doing stuff that requires transforming data can be tricky.
• NW: What should we do next?
• CG: I feel like this one is pretty near done.
• MK: Maybe we should accept it and then work on improvements.
• WP: I think that makes sense.

Proposal: accept this PR.

• MK: With the expectation that I’d like to propose some changes…

Accepted.

• CG: One fairly obvious extension could be a rename function. Renaming is a bit tricky.

See PR #2885

• CG: Using integer everywhere has problems with a function like replicate where a negative number makes no sense.
• CG: In #2849, I listed a bunch of possibilities.
• CG: My proposal is to generalize many of those cases and instead use specific error messages.
• MK: I’m happy to go with that.

Proposal: accept this PR.

Accepted.