QT4 CG Meeting 162 Minutes 2026-04-28

• [X] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [x:10-]
• [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 5 May 2026.

No regrets heard.

• [ ] 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.
• [X] QT4CG-150-04: NW to see about a status update on PR #2345; possibly schedule discussion
  • Absent any recent feedback, I propose closing this for now
• [ ] 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.
• [X] QT4CG-161-01: MK to add a record parameter to the dm:record-get accessor. (Editorial)
• [X] QT4CG-161-02: MK to review the build-dateTime example in with and correct as necessary.
• [X] QT4CG-161-03: MK to review the grammar; with seems to be unreferenced.

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

• MK: This was previously bundled with the proposal for an fn:regex function; it’s now been decoupled as requested.
  • … It’s sort of equivalent to xsl:analyze-string except that it returns the information in map form.
  • … It returns all the information about how a regex matches an input string in a single shot: including groups, etc.
  • … It relies on disjoint matching segments which we already define.

MK reviews the examples in the specification.

• NW: Is it possible for the group keys to be non-sequential?
• MK: Yes, it’s a map because it can be sparse.
• JLO: Do we have an option to name groups?
• MK: No. That’s a feature of some regex dialects.
• JLO: We now get a sequence of maps only with matching segments. If I want to construct the string again out of the segments, that will be challenge.
• MK: A challenge for the reader! (Might be nice to have an example showing that.)
• JLO: In the date example, we do match on the hyphen, but they aren’t in the output. Is that intended?
• MK: Yes, it’s part of the substring as a whole but not of any group.

MK points back to disjoint-matching-segments where the processing model and logic are outlined.

Proposal: accept this PR.

Accepted.

See issue #2489.

This issue is marked propose closing after discussion.

• CG: I wondered whether we should change than name of a couple of functions.
  • … Majority of feedback was negative, I’m fine with that.

Proposal: close this issue with no further action.

Accepted.

See issue #2314.

This issue is marked propose closing after discussion.

• CG: There was a long discussion in this issue; MK suggested changing the return type.
• MK: From the perspective of a reader of the spec, a return type of xs:error makes more sense.
• JLO: Why is it a problem to implement xs:error as the return type?
• MK: We declare the return type as item()* because it stops the optimizer from making inferences and optimizing it away.
• CG: Ok, I’ll do a PR.

Okay, that issue will get closed by that PR.

See issue #2312.

This issue is marked propose closing after discussion.

• CG: I wonder if we should remove some syntactic sugar. The syntax filter(?key, ?value) isn’t used anywhere else.
  • … We could just use map filter functions.
• MK: Remove the predicate for both maps and arrays. I think I’d probably go along with that.
  • … We started out with the idea that if something can be done with sequences, it should be just as easy with arrays.
  • … But it’s another bit of syntax for people to remember and FLOWR expressions are probably the first thing people will turn to. But there’s now where clause in XPath.
• RD: What’s the objection to adding the where clause to XPath?
• MK: The where and order by are the only things that operate on tuples of variable bindings.
  • … You can do weird things with that; it adds quite a bit of complexity. It doesn’t reduce to just doing two nested for expressions.
• JWL: On the for key $key value $v … expression key and value are both keywords.
• RD: value is full-text? It’s one of the extensions.
• JLO: I have never noticed this syntax before; I found this hard to explain. I’m in favor of dropping it.

Some discussion of the syntax of the example and how arrays and sequences relate.

• MK: Not listed here, there are also ways of doing this with JNodes.
• CG: I can do a PR for it.

See PR #2593

• MK: This is removing some functionality in the interest of making things simpler.
• MK: We get rid of the number-parser function and replace it with number-format that has three possible values.
  • … This is to do with what you do with numbers in the parse-json function.
• MK: In XPath 3, you always get double.
• MK: You can now choose to between double and decimal or base it on the lexical form.

MK describes the options.

Some discussion of different options for different fields. No, you don’t get that.

• CG: My preference would have been to make the adaptive behavior the default, but I can see why it isn’t.

Proposal: accept this PR.

Accepted.

See PR #2589

• MK: This is all in the streaming spec.
• MK: This is a partial response to the long standing action that says we need to define the streamability of new construct.
• MK: Changing context item into context value caused lots of problems on my first attempt.
• MK: This is my attempt to define things so that it’ll work.

MK reviews the streamability rules for new constructs.

• MK: I’ll revise this after we accept the PR that removes map and array filter expressions.

See PR #2566

• MK: The only new thing here are some specific corrections from our review and in addition the conflict with the query update syntax using the with operator.
  • … I changed the with operator to +:= (the record put operator).
• MK: I also restricted it to records as requested.
• MK: There is more work needed on types and instance of. It’s complete in it’s current form, I think it’s a good checkpoint.
  • … Named vs anonymous record types in instance of needs some more thought.
• CG: I think it could be worthwhile to look at the comments on this PR.
  • … The XQFO spec still talks about raising errors; other parts of the spec says the functions behave as before.

MK will review the comments and bring it back.