QT4 CG Meeting 165 Minutes 2026-05-12

Regrets: AP, JLO.

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

JK points out that PR #2595 was accepted last week. I’ve removed it from today’s agenda.

Proposal: Accept the agenda, as amended.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 19 May 2026.

Possible regrets from DB.

• [ ] 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.
• [X] QT4CG-165-01: NW to follow-up with the generator authors and schedule another discussion
  • NW sent email today

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 #2616

• MK: There is a technical change here.
  • … One of the comments last week asked about what would happen if you put array-member in place of sequence in the example.
  • … They’d be double wrapped
  • … So I’ve changed the specification so that it doesn’t double wrap them, or raise an error.
• JWL: There’s a bit about never using array member in a for each; would that raise a static error?
• MK: That’s a good question. Yes, you’d get XTDE4060. It could be detected statically sometimes.
  • We could possibly make that a type error.

Proposal: accept this PR.

Accepted.

See PR #2611

Not ready for discussion.

See PR #2609

• MK: I think there’s a cosmetic change in XQuery, but the substantive changes is in F&O.
  • … Yes.
• MK: In F&O, we add introductory material to 16.1, Functions on JNodes
  • … The text on fn:jtree changes. In particular, the second paragraph about identity.
  • … The concept of identity for maps and arrays is only weakly defined.
  • … I’ve simplified some of the examples.

Proposal: accept this PR.

Accepted.

See PR #2603

• MK: There are details about what the implications are.
• MK: In XQuery,
  • … In conformance, we list the details about what it means to support the Binary Library Feature
  • … (Or what it means not to).
  • … For the File Library Feature, the requirement is imposed that you provide implementation-defined mechanism related to side-effects.

Proposal: accept this PR.

Accepted.

See PR #2601

• NW: I think Sheila has done what we asked.

Proposal: accept this PR.

Accepted.

See PR #2596

MK introduces the PR; this is a slight revision of what we had before.

• MK: I see this as a step in a pipeline; the project of applying template rules to maps and arrays in trees is currently incomplete. We still need to define builtin templates, modes, and such.
  • … But we need better match patterns for them.
  • … Matching maps by type annotations means that we need additonal mechanisms to match structurally.
• MK: It’s a new top-level pattern, MapPattern.
  • … (The expansion in 6.3.2.4 is too verbose; but that’s editorial.)

MK describes the syntax and walks through the following examples.

• MK: The default priority rules are pretty basic and follows the general principles.
• JWL: In the first example, how would write the pattern that I wanted something to be either the first or the last?
• MK: You can’t do that directly.
• JWL: The keys can be QNames, could you end up with a QName with a colon in it?

Some discussion of wether or not the colon could be ambiguous. Consensus: no.

• MK: The usual problem with colons, that you need to follow them with a space, will apply.
• JK: I think the PR is great, I wonder how record types will be invoked in the match pattern.
• MK: Yes, that’s a separate topic because records are changing and I’m trying to keep things separate.
  • … This is one step along the way.

Proposal: accept this PR.

Accepted.

See PR #2566

• MK: This has been reviewed before; this is a response to comments.
• MK: It’s a data model change, so we’ll start there and then go to the XQuery spec.
• MK: In the data model,
  • … A record is now a distinguished thing. It’s a map that is constrained by a record type definition.
  • … In the type hierarchy, record is a subtype of map.
  • … A record has a type annotation.
  • … Section 8.3 outlines what a record is. Two new accessors:
    • … record-get-value accessor
    • … record-replace-value accessor
  • … The key thing about replace value is that it constructs a new instance of the record type with the same type annotation, so the replacement may not change the type.
• MK: In XQuery,
  • … We reintroduce syntax for AnyRecordType.
  • … Record types are defined in the appropriate section.
  • … The whole purpose of the proposal is to enable stronger type checking.
  • … At the time of writing, it’s not required that an instance of check must have the same type annotation. It’s structural.
    • … I’m not sure if that’s going to be the final state of affairs.
    • … If we want to do a check on the type annotation, we need to introduce derivation so that one record type can extend another.
  • … For the moment, this is workable but we could go further.
  • … Records are created by coercing a map to the required record type.
  • … Record types may be anonymous or named, for useful reasons.

There’s an open editorial issue that we need an appendix that lists all the builtin record types.

• MK: Using a record type in a signature causes coercion to happen.
• MK: Record are maps, so they’re also function items. We explain the signature of the corresponding function item.
• MK: Some slight changes in the subtyping rules.
  • … Fields are no longer optional or mandatory, but they can be empty.
• MK: Coercion rules are defined for records.
• MK: There’s a new RecordPutExpr, (+:=)
• MK: It’s a type error to attempt to access a field that’s not part of the record type.
• MK: There’s a new operator +:= that updates a record.
  • … The +:= operator is type safe.
• MK: Some examples are updated.
• MK: You can declare record types in the prolog.
  • … It’s simplified because we no longer have optional fields; the constructor functions are much simpler.
• MK: That’s basically it, other specs are updated in equivalent ways.
• CG: Thanks again. I think my comments haven’t been incorporated yet. Could we look at those?

MK agrees to review the comments.

See PR #2594

• CG: This basically results from user feedback. It effects the adaptive serialization method.
• CG: As JSON becomes more common, we regularly encounter numbers that represented as doubles, so 100 becomes 1E2.
  • … To make the adaptive serialization more useful, I propose making some of these more implementation defined.
• CG: The “&” needs to be escaped to “&” in strings for XQuery, but not for XPath.
• MK: The question is what are we trying to achieve. The reason for the numeric format had in mind a sort of debugging use case.
  • … It’s intended to signal that it’s a double not an integer. It allows users to tell that it’s not an integer. That’s appropriate for some use cases and not others.
  • … Generally, the whole issue of escaping characters that might be hard to distinguish is tricky.
  • … I thought it was a bit odd to escape “&” without also escaping angle brackets. But I can’t give a precise rational.
• RD: The challenge with things like non-breaking space is that it’s used in some cases in French. And it’s used in publishing to keep things together.
• MK: You get non-breaking hyphens as well.
• RD: Also, the familiy character in emojii has a non-breaking space in the middle. Messing with those can effect rendering.
• CG: What I can add is that in our use cases, we also have a custom serialization for BaseX. Maybe we shouldn’t use adaptive at all. As MK says, it’s difficult to give an answer for every use case.
• RD: With numbers, don’t we have the decimal format specifier to indicate how to format numbers?
• MK: You could add lots of parameters, but it’s hard to imagine them all being used.
• RD: The default should be usable but provide options for users to override that.
• CG: It can be tricky, because it depends on where you use it, which is also implementation-dependent.
  • … You can use it for trace output, but you don’t have to, …
• MK: You can see the output actually being someting interactive, where it’s clickable, or copy-and-pastable.

The current state isn’t satisfying.

• CG: What would the drawback be if we made more features implementation-defined?
• RD: You run into interoperability problems.
• MK: One advantage of making it implementation-defined is that it discourages people from believing that it’s intended to be machine readable.
  • … Making it clear that this isn’t intended to be consistent.
• CG: Okay, maybe I’ll have another try.
• WP: I think the big risk is that people will be surprised by the changes.
  • … I think what we’ve heard is correct, it’s not really a solvable problem in the standards.

CG will make another PR.