QT4 CG Meeting 161 Minutes 2026-04-21

Regrets: JWL; RD may be late.

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

Proposal: Accept the agenda.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 28 April 2026.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-144-01: MK to consider if any now lost value comparisons should be added as examples.
• [ ] QT4CG-150-04: NW to see about a status update on PR #2345; possibly schedule discussion
• [ ] QT4CG-156-01: MK: add reference to data model in F&O 9.2
• [ ] QT4CG-156-03: MK to revise PR #2516 in light of the comments.
• [ ] QT4CG-158-01: MK to revisit the Conformance section to revise in light of #2556 error changes
• [ ] QT4CG-158-02: MK to add system-properties() keys for file and binary support
• [ ] QT4CG-160-01: MK to fix the markup error in method/method call in #2578
• [ ] QT4CG-160-02: NW to think about how to promote the dated drafts for broader community feedback.

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

• MK: We had an extensive discussion a couple of weeks ago. I’ve tried to respond to that discussion.
  • … I’ve also added CG’s with operator.
  • … There’s been a fair bit of comment, I think it’s worth going through again.
• MK: Let’s start in the Data Model and then XQuery and then proceed from there.

MK reviews the Data Model.

• MK: A record is now a defined thing in the Data Model.
  • … Consequently, they appear on the type hierarchy.
• MK: Records have a type annotation and a definition of a type annotation is extended.
• MK: There’s a new section on records (8.3)
  • … There are two new accessors: dm:record-get and dm:record-put which behave differently.

ACTION QT4CG-161-01: MK to add a record parameter to the dm:record-get accessor. (Editorial)

• MK: There’s a problem defining it purely as a function because it sets a type and that’s not clear from the function syntax.
• JLO: Both accessors have a record* as their input and output; shouldn’t it be made clearer that you get the same kind of record out?
• MK: That would invent a formalism; it would be nice, but not clear it’s worth doing.
• RD: Is it explained in the text that the returned record type is a supertype of the input record.
• MK: The Data Model doesn’t define much about the type system.
• RD: Describing it in prose rather than inventing a formalism.

Some additional discussion without any clear resolution.

• JLO: I think we have ElementA that is an existing formalism.
• MK: It’s a bit of a tangled mess.
• RD: Stating that it’s a subset or equal should be sufficient.

MK reviews the XQuery specification.

• MK: The grammar reintroduces AnyRecordType for convenience.
• MK: We recapitulate the definitions of record and record type;
  • … AnyRecordType is record(*) again.
• MK: For the moment, I’ve kept the structural definition of instance of.
  • … You’re an instance if you have the right fields and values.
  • … I’m not 100% happy with that; it feels like if you have a type annotation it should be used to check the type.
• MK: We have a mixture of structural and named typing already.
• MK: The instance of operator is based on type labels for atomic values and nodes.
  • … But the coercion rules are based on structural matching.
  • … You can call a function with an integer if it expects a positive integer but instance of checks the type label.
• MK: I think we should make it work that way for records, but I haven’t done that yet.
• MK: This is closely related to have XSLT pattern matching relates to coercion and instance of
• MK: The rules for when a map matches a record type are defined.
  • … This is where there are no uses of the type annotation.
  • … Record types are created by coercing maps.
• MK: Record types may be named or anonymous. The benefits of named records are outlined.
  • … Some named record types are built into the fn: namespace.
• MK: The binary tree example has been updated to use a record type.
  • … There’s no distinction between a field that’s absent and a field that’s empty.
• JLO: Is there a difference between declaring a type and a record?
  • … You only get the constructor if you declare a record directly instead of declaring a type that’s a record.
• MK: I think that’s been moved into the section where record construction is described.

Some discussion of missing keys in maps vs missing elements in arrays. Attempting to get a non-existant map key returns an empty sequence. Attempting to access an array element that’s out-of-bounds raises an error.

• MK: Two named records with exactly the same content are mutually exchangable for subtyping purposes, but not perhaps for instance of purposes!
• MK: In the section on coercion rules:
  • … If the required type is a typed record type and the provided type is a map; the coercion rules are spelled out.
  • … Entries in the supplied map that don’t match a field are discarded.
• MK: On to lookup expressions:
  • … The lookup operator now raises an error if the key is not in the record.
• RD: With functions like fn:serialize, we’re defining a record for the options?
• MK: No, that’s a map. Where we want it to be open ended and extensible, we have to use a map.
  • … If you want the set of keys to be open-ended, you have to use a map.
• MK: Next we introduce the with operator:
  • … The with operator can update a map or record.
  • … The operator applies to any map, not just to records, but there’s a special rule for records.
  • … The result will always be the same type as the first operand and an error is raised if that’s not possible.

Some discussion of the build-dateTime example;

ACTION QT4CG-161-02: MK to review the build-dateTime example in with and correct as necessary.

• MK: I think with is associative, but I haven’t proven it to myself.
• JK: I see the with expression defined in the grammar, but is it used?
• MK: We can check that, it should be referenced from the next part of the grammar.

Some discussion of mixing maps and records; basically, it depends on the left hand operand.

• MK: Some of the examples have been changed, as expected.
• MK: Constructor functions for named record types are simplified; we no longer have optional and extensible to deal with.
• MK:

ACTION QT4CG-161-03: MK to review the grammar; with seems to be unreferenced.

MK reviews the Function and Operators specification.

• MK: There are some small changes; like the lack of optional fields in records.
  • … fn:build-dateTime is also simplified by this.
• JLO: If I’m still planning to use map:put, do I still get back a record?
• MK: No, you get back a map.
• JLO: Is that clear somewhere?
  • … I’d rather see map:put be equivalent to with.
• MK: There’s a substitutability issue there.
• CG: After reflection, I think it’s better to make maps and records more distinct.
  • … If you have a record and you use map functions, it’s not immediately obvious that you’re using record types.
  • … You need extra syntax to get out of the “record box”. I think this is more flexible and extensible.

MK reviews the XSLT changes.

• MK: Optional fields are removed. Some examples are updated.
  • … The XPath changes to the grammar picked up.
• MK: The xsl:record instruction has been redesigned a bit.
  • … It was getting messy with the distinction between attributes that represent fields and attributes on the instruction.
  • … I added a xsl:with-fields instruction to cope with that.
• MK: The example that has an optional field has been reworked.
• WP: On xsl:with-fields, would select with a map be better?

Some discussion of that option.

• MK: We don’t really need xsl:record.
• WP: It just looks a little odd to me that we allow those attributes to be user defined.
  • … I like it as syntax sugar, but I think it can be improved.
• MK: I’m of half a mind to get rid of xsl:with-fields as it doesn’t add enough value.
• RD: I wonder if mixing xsl:with-fields and map:key elements would make it more interesting?
• JK: I like xsl:record, I have a different preference. I think it should be xsl:with-field and I should be able to repeat them. That way I can use use-when and static parameters.

NW, WP express a fondness for that approach. JK to consider writing it up as a separate proposal.

• MK: The question is where do we take this proposal from here?
  • … The big open issues are how we do instance of and subtyping: are they structural or named?
  • … And I haven’t tackled the relationship to XSLT pattern matching when you’re transforming JSON.
• CG: I really like the proposal. I’ve already given some comments:
  • … In the coercion rules, I think we should disallow entries that aren’t in the record, not discard them.
• JLO: I agree; my assumption would be that it was a type error to attempt to do that.
• MK: Then you don’t get substitutability by extension that we’re used to in OO languages.
• NW: Would a function that “gets the record out of the map” be a thing?
• MK: It would be nice if we had types as first class objects.
• CG: It would be nice to handle dynamic function calls in the same way.
• CG: Maybe dm:record-put should be renamed to dm:record-set? Put implies you can add to it.
• CG: Thanks for adding with. My preference would be that it’s restricted to records; we already have many ways to update maps. That restriction would also make it easier in the future, perhaps.

Some discussion of what comes next.

• WP: I think it’s moving in the right direction. The key question is going to be usability.
  • … Looking at pattern matching is going to help.
• JLO: Coming back to instance of; I’m a fan of it being structural.