QT4 CG Meeting 182 Minutes 2026-09-29

• [X] 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)
• [ ] Ruvim Pinka (RP)
• [X] Wendell Piez (WP) [x:10-]
• [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 6 October.

No regrets heard.

• [ ] 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-167-09: NW to close all “nice to have” issues at the end of October if they haven’t progressed
• [ ] 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.
• [X] QT4CG-181-01: CG to open an issue about a possibly better name for “the url base64url” function

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 PR #2934

• MK: I made a more radical proposal, but I’ve withdrawn that. This is an attempt to address the specific issue: named vs. “plain” record types.
  • … I thought this would be purely editorial, but I discovered various inconsistencies that needed to be sorted out.
  • … Subtyping and matching instances were a bit muddled.
• MK: The substantial changes are all in the XQuery spec.
  • … named -> nominal -> nomative, but there’s some residual messiness in the links.
  • … The section on types has been flattened a bit to avoid deeply nested headings.
  • … Function and map types haven’t changed.
  • … Record types have changed.

MK walks through the changes to the record types.

• MK: There are two cases, structural record types and nominative record types.
  • … The matching rules now are that they must both be defined as records and must have the same fields.
  • … Different definitions for structurally identical records are interchangeable.
  • … Maps can be converted to records either by coercion or casting.
• MK: In nominative record types,
  • … The are always named and can only be referenced by name.
  • … The differences and benefits of names are explained.
  • … The name isn’t a unique identifier for a type, it’s the existence of the declaration that counts.
• MK: In the subtyping rules, the rules for structural record types are based on comparing them.
  • … You aren’t allowed to have extra fields in either direction.
• MK: In the subtyping rules, the rules for nominative record types, we don’t have subtypes currently.
  • … But nominative record types are subtypes of the corresponding structural record type.
• MK: The section on nominative record types in XQuery changes terminology but not much else.
• MK: The corresponding changes are also made in XSLT and F&O has been updated to refer to the nominative record types.
• JWL: If you have two nominative record types with the same structure, they aren’t the same.
  • … But they can both be the subtype of a structural record type.
  • … So if I’m calling a function that has a nominative record type as an argument and I provide the corresponding structural type, will coercion work?
• MK: Yes, coercion will work.

Some discussion of coercion. Coercion will work across several cases, but what doesn’t work ins instance of.

• JK: I think this is misnamed; “nominative” is the wrong term to use.
• MK: I changed it at a fairly late stage from nominal to nominative. I thought “nominal” wouldn’t be recognized as a technical term.
• JWL: What was the objection to “named”?
• MK: You can give any item type a name by putting it in a named item type. That is a much broader sense. That’s not at all like changing it’s nature to use nominal typing rather than structural typing.
• WP: I did throw a term out in the chat, “denominated”?
• CG: I’m no expert on terminology. “Nominal” seems common, “nominative” seemed unfamiliar.
• NW: It is at least a distinct term of art in our specification!

Proposal: accept this PR.

Accepted.

See PR #2932

• CG: It might have been helpful to have single PRs for each of these, but I didn’t do it that way.
  • … This is the result of feedback rounds from users for helpful functions.
• CG: I don’t anticipate any more requests of this kind.

CG begins with fn:distinct-by.

• CG: It decides if two items are distinct by computing a key. It’s very similar to fn:distinct-values.
  • … It’s also similar to the fn:sort function.
  • … There are cases where fn:distinct-values isn’t enough.
• MK: Why don’t we do grouping rather than just return one item?
  • … This does seem to be doing the same as group by in XQuery and xsl:for-each-group in XSLT except that it’s computing the grouping key slightly differently. It would be nice to do grouping as a function, we have fn:partition that does a little bit of that.

Seems a bit controversial.

CG proceeds to fn:drop-while.

• CG: We’ve rejected this before, but the request has come back.
  • … It’s fairly trivial.
• MK: I don’t feel that subsequence-where is ideal; it came out of a case where a lot of alternatives had been proposed.
  • … In Saxon we had four functions, for before, after, from, and to. One is equivalent to fn:drop-while.
  • … It is a better name if people know it.
  • … I’d be happy to look at that area again. But I’m not happy to just add another function that duplicates the functionality.
• JK: I wonder if it would be better if it was inverted and call it drop-until and invert the condition.
• JWL: If we’re happy with subsequence-where, which maybe we aren’t, we could add subsequence-where-not.
• WP: Does anyone have “keep until”? That seems more normal to me.

Seems a bit controversial.

CG proceeds to fn:random-number-generator.

• CG: People have trouble using it because it requires fold-left and higher-order functions.
  • … This addsa take function that takes the first “n” items of a sequence.
  • … There are ways to do this with fold left, but I think this is easier.
  • … In BaseX we have custom random functions but when you want to use the standard then this may be helpful.
• JLO: I’m in favor of this. I created a module to make it easier to do exactly this kind of thing.
  • … If you say fn:take(10), you’ll lose the random number seed. That’s a problem. It can’t then be used like a random number generator.
• CG: For more complex cases, you need to use recursive code or fold left.
• JLO: If you remove all the code that does the more complicated thing, it’ll be harder to find later.
  • … We should clearly state that this is only for the easy case.
• MK: I withdraw my objection to this one. I thought initially we didn’t need both permute and take, but I think they’re sufficiently distinct.
  • … What fn:permute does is actually entirely different. It might be useful to draw out that distinction.
• JWL: If we have fn:permute with an interesting action that basically produces the permutation but doesn’t disturb the seed, why can’t we do the same for take?
• JLO: It is easier if you don’t have to call another thing after that. It would be nice to still let users jump through the hoop.
  • … I may suggest that we have a completely separate function that does it in the way intended. There’s more to it if you want to select a random thing out of a set of things. Building blocks would be good.

This also seems a bit controversial. But later in the call, that was resolved. So it’s accepted.

CG proceeds to fn:index-of-substring

• CG: You can check if an item is contained in the sequence and return the position. This does the same thing for strings.
• MK: We need to decide whether it only returns no-overlapping substrings.
• CG: It does say that in the notes.
• MK: Oh, okay. In the presence of collations, it’s not easy to determine reliably where the match ends. The length of the match isn’t the same as the length of the substring.
• CG: That’s why I dropped collations.
• JWL: Don’t we have something very similar in the binary with bin:find? No, that only produces the first case.
  • … Do we need the same thing for substrings?
  • … Does it produce the first one or a lot?
• CG: You can do it one way or the other, I thought it would be better to be like fn:index-of.

Proposal: accept fn:index-of-substring.

CG proceeds to fn:trim-space

• CG: This one does what the name says.

Proposal: accept fn:trim-space

CG proceeds to fn:substring-before-last and fn:substring-after-last

• CG: One common use case is when you have filenames and you want the file suffix.
  • … You can try to use regex or tokenize, but there are lots of special cases.
  • … It seems to be popular in some code bases I’ve looked at.
• MK: These two do still have a collation, so they’re collation dependent.
• CG: Yes, they’re very similar to substring-before and substring-after.
• MK: Yes, doing it without these functions does require a bit of arithmetic.

Some discussion of when zero length strings are returned.

• AP: If it’s inspired by functx, do we have a reference somewhere?
• CG: There’s one reference. We should check what else we’ve adopted.

Proposal: accept fn:substring-before-last and fn:substring-after-last

Accepted.

CG proceeds to fn:duration-to-seconds

• CG: This is the inverse of the fn:seconds function.

Proposal: accept fn:duration-to-seconds

Accepted.

CG proceeds to fn:days-in-month

• CG: It gives the number of days in the month, including leap months.
• JK: Might need a note indicating that it does not work for February before the 16th century.
• MK: Yes, it’s the proleptic Gregorian Calendar not the Gregorian calendar.
• MK: I think there should be a link to the ISO spec, that’s where the proleptic Gregorian Calendar is defined.

Proposal: accept fn:days-in-month

Accepted.

CG will make another PR for the accepted functions and divide the controversial ones into separate issues or PRs as appropriate.