QT4 CG Meeting 165 Minutes 2026-05-19

Regrets: DB.

• [ ] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [X] Wendell Piez (WP)
• [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 26 May 2026.

CG gives regrets for 2, 9, and 16 June.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-160-02: NW to think about how to promote the dated drafts for broader community feedback.
  • Withdrawn.

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.

PRs #2633-#2638 reflect the output of a commercial LLM. The community group should decide, before discussing these items, what its policy is going to be on LLM generated content. This is a policy choice that needs to be made first because accepting them, or not, will establish a policy.

• NW: I posted my thoughts, I won’t read that email.
• AP: I had to read the PRs; I thought it was interesting to see how detailed they are. There are quite a few corrections. Do we just throw them away.
• NW: I believe we should reject them.
• CG: I’d be perfectly fine to reject them. I have manually checked all of the edits and left aside the larger suggestions; I’ve left the majority of the text intact. I think it would be okay to use AI for checking and validating thing. That’s what we do in our company.
• MK: It’s a tough one. I think part of it is to do with the fact that we don’t manage our contributors. We don’t know what tools they use. It’s not a binary issue. We’ve historically applied gradually increasing amounts of automation for quality control. In a sense this is just the most recent step. If you use Google now adays, it’s using some AI. Stack Overflow has been killed by AI. In the past, I’ve used spell checking and grammar checking tools. Those increasingly have some kind of AI incorporated. Exactly what that means, I don’t know. Sometimes it’s just a marketing buzz word.
  • … At some level, I think we need to judge a PR by its content, not by how it was created. Clearly some edits would be impossible to check, like rewriting the whole specs. But I’m not greatly concerned about how it was created.
  • … It’s not our job to say what tools you can use.
• JLO: I think a lot of good things already have been said. I agree with Norm. But I can’t control contributions to the open source projects I work on, so my life is different now.
  • … I’ve seen us making great progress even though you have to be very wary.
• WP: I agree with everything that’s been said so far. I think MK makes good points about enforcability.
  • … LLMs aren’t reproducible, they aren’t transparent, they aren’t accountable. What we’re faced with is, as a community, who is standing up for this?
  • … There’s a big difference between specs and software.
  • … I’d rather work based on criteria in the PR.
• JK: I’ve said in response to Norm’s email that I largly support a policy that says no to unmediated LLM tickets. I’m less reluctant to police other people’s efforts.
  • … The question I have is, “if I want to know if we’re using the Oxford comma’s, AI tools are the easiest way to do that.”
• NW: A policy is something that we agree to uphold; we have to trust each other to abide by the rules we agree to abide with! My concern with allowing any form of LLM generated content is that it’s the camel’s nose. And I don’t want to spend time analyzing statistically generated plausible text.
• WP: I think what you said is exactly right. But it’s a trust issue.
• JLO: I expect anyone to be able to explain what happens in their PR irrespective of the tool they use. Tools are tools. There’s one little word in your text “commercial” LLMs.
• CG: I’ve been using a tool that helps German writers write better English. It’s more LLM today than it used to be. But it’s helping me write good text. The question is what should be okay for me to contribute?

ACTION QT4CG-165-01: NW to attempt to draft an AI policy.

See PR #2611.

• MK: I did another draft, it’s worth taking a look.

MK walks through the changes.

• MK: CG has raised the point that this might be better done with caching.
  • … But given that we belief that we do need this kind of thing, this is an attempt.
  • … I’ve changed the examples so that they’re clearer.
  • … There are examples that call matches more than once, one that uses flags, and other attempts to make illustrative examples.
• MK: The record type exposes the type and the flags. They’re described in terms of the function.
  • … If you take the functions out of context, you’re off the reservation.
• AP: Is there any chance this could be called from inside the xsl:analyze-string instruction?
• MK: That’s a really good question!

Proposal: Accept this PR.

Accepted.

See PR #2566.

• MK: I have done work on this; there have already been comments.
  • … I did review all of CG’s previous comments and I’ve attempted to address them; in most cases by changing the spec.
• MK: There are some current comments that I haven’t addressed.

MK reviews the changes by looking directly at the commit diffs.

• MK: The constructor is a pseudo-function because it takes a type as one of its arguments; I’ve tried to fudge that.
  • … You take a map as input and a record type and you adjust the map, returning the record.
  • … Getting the value from a record is different than getting it from the map because you raise an error for missing keys.
• MK: I’ve made the examples clearer.
• MK: Some of the changes here are from the PR that dropped extensible record types.
• MK: I’m going to have a rethink about how we match against a partial type, but I think that’s a different program of work.
• MK: Coercion is not specifically related to records, but it’s not economically feasible. It has to be a straight instance of test in the interest of efficiency.
• MK: There’s a note that points to map patterns which are sometimes a better approach.
• CG: I’ve closed all the comments that I think are resolved. Two are still open, but I think the’re easy.
• MK: The status quo is that lookup expressions and function invocation throw the type error if the key doesn’t exist, but map:get doesn’t.
• CG: It still says that map:get throws a type error.
• CG: The first item in one of the examples is a function when it should be a map or use the function operator.
• JWL: We’re getting into an area where “record” is definitely a very typed constraint on a map. It might be worthwhile emphasising that somewhere.
• MK: You can still treat it as a map, but you don’t get a record back if you change it.
• JWL: But if you put…
• MK: If you use map:put, you get back a general map.
• JK: I like the PR, what’s missing (or perhaps I missed) is how default values are expressed in XPath.
• MK: We don‘t have a way of creating costructor functions in XPath, apart from the built in ones. So there’s no XPath mechanism for declaring a named record type.
• JK: Are we going to try to do that?
• MK: It’s hard to find the right cutoff point; it would become XQuery.
• CG: Note to JWL maybe, if you have a record and you do a map:put and then coerce it (for example in return a type from a function), so there may be real opportunities for optimization here.

MK would like to merge this and address outstanding comments later.

Proposal: Accept this PR.

Accepted.

See PR #2626.

• MK: I put forward a PR to change fn:subsequence (a while ago) and I was surprised to discover that failed to do it to fn:substring.
  • … We’ve always accepted xs:double, and there are weird historical reasons for accepting INF.
  • … But we’ve always implemented as xs:numeric so it fails a few tests.
• MK: The change is pretty straightforward, but I did also change fn:subsequence to bring them in line.

MK notes that there’s a cut-and-paste error in fn:subsequence.

• MK: Moving on to fn:substring~…the arguments are now defined as ~xs:numeric.
• JWL: If you’re going to do this, do we also want to do it to the binary functions as well?
• MK: No, they were never xs:double.
• JLO: Why can’t we make it xs:integer here?
• MK: If it was integer, the number you supply would have to be an exact integer. You’d get a compatibility problem for places where 1.001 might be used.

Proposal: Accept this PR.

Accepted.

MK to merge the PR after fixing the obvious cut-and-paste errors.

See PR #2627.

• MK: This arose from Sheila’s work on tests that were returning different error codes than expected.
  • … XPTY0019 and XPTY0020 have always overlapped. There are cases where either is allowed.
  • … And they’re type errors so they can be detected statically.
  • … So let’s just ditch them and use `XPTY0004~

MK reviews the details of the change.

• MK: I’ve fixed a statement that wasn’t technically true.
  • … The rest of the changes are just changing the error codes.
• NW: Is there any reason to worry about backwards incompatibility in a try/catch
• MK: The try/catch is going to be unreliable anyway because they might be caught statically.
  • … So I think the risk is pretty low.

Proposal: Accept this PR.

Accepted.

• Expected: AP, MK, NW, JLO, DB
• Triage the issues list
  • NW proposes we need to be agressive about closing issues; we should warn folks who won’t be at the face-to-face.
• Scheduling
  • Call for comments, consultation, drafts, etc.
• Work on big issues while we’re together?
  • Use case for JSON transformations would be a good one to workshop.
  • Another look at trusted execution?
• Plan for a one hour Zoom call at the end of the day if anyone wants to join remotely for discussion

ACTION QT4CG-165-02: NW to draft an agenda for the face-to-face meeting