QT4 CG Meeting 168 Minutes 2026-06-16

Regrets: CG, BTW

• [X] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [ ] 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)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW) Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of 26 May 2026 (teleconference).

Accepted.

Proposal: Accept the minutes of 2 June 2026 (face-to-face).

Accepted.

The next meeting is planned for 23 June.

AP gives regrets.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-167-01: DB to write a PR for #2641, comments in CSV
• [ ] QT4CG-167-02: MK to make a PR for #2591, grammar for step?lookup is invalid
• [ ] QT4CG-167-03: NW to make a PR for #2482, fallback on bin:decode-string
• [ ] QT4CG-167-04: NW to make a PR explaining load-xquery-module for PR #2464
• [ ] QT4CG-167-05: MK to write a proposal to change #2393 so the functions return JNodes
• [ ] QT4CG-167-06: NW to write a PR to resolve #2169 per GuntherRademacher
• [ ] QT4CG-167-07: NW to review tests for interpolated strings with edge cases in mind
• [ ] QT4CG-167-08: MK to review the state of #1949 to see which items are still outstanding.
• [ ] QT4CG-167-09: NW to close all “nice to have” issues at the end of October if they haven’t progressed

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 Issue 2683

• MK: This is a binary decision, so let’s see which the group prefers we write it up.
  • … The spec is contradictory.
• MK: In general, an expression is allowed to return a subtype of the requested. Should that be allowed for constructors and cast expressions?
• MK: What I want to propose is that the general rule applies, but casts and type constructors are an exception to that rule.
• NW: I think that makes sense.
• JLO: I think the question will be, will we see any errors from this?
  • … It would only raise an error when you do a cast to decimal and then do instance of and it isn’t a decimal.
• MK: The general rule does mean that you can write things that aren’t interoperable.
  • If Saxon returns 4 div 2 as an integer and BaseX returns it as a decimal, you might not have interoperable code.
  • If you’re calling a user defined function, you can’t constain a user defined function to return an integer when it’s declared type is decimal.
  • Why shouldn’t the same rule apply to system defined functions?
• JLO: In my head, I think we might want to say that you have to return the type specified and the implementation may used a value internally that’s unchanged.
  • Treat it as a boxed value.
• MK: We clearly can’t do that with user defined functions.
• JLO: Maybe I’m not sure what you mean.
• MK: If a function declares a return type of xs:integer?, you can return () which is a more specific type.
  • … Maybe that’s a bad example. Let’s say it returns xs:decimal and on one branch of a choose you return 0, that’s an integer.
  • … We don’t cast that to a decimal, it comes back as the integer 0 and instance of will say it’s an integer.
• JLO: I’m not sure. I’d really expect that if it says it returns decimal, that’s what I get back.
• MK: That would clearly be problematic.
• JWL: If you’re calling a function that expects an xs:decimal, you can pass in an integer. That’s fine.
  • … It’s effectively symmetric on the way out.
  • … What you require is a xs:decimal but an integer is a decimal.
• MK: It’s basically the principle of substitutability, which you can break with instance of.
• JLO: Okay, I think this makes more sense. But we need to make it clear that instance of may not do what you think it does.
  • … You may need to do something else. Maybe castable as.
• MK: The instance of check works if it belongs to a subtype.

Some discussion of where the problem arises. If you test if the value returned is an integer, then you may see different results from different implementations.

Consensus: go with Mike’s proposal for a special case.

See PR #2678

• MK: I suggest we go through the non-diff version. The diff makes it looks like a bigger change than it is.
• MK: The changes are in Patterns, 6.3. I’ve flattened things slightly.
  • … Patterns now fall into six groups at the top level: predicate, type, XNode, map, array, and JNode.
  • … Predicate and type patterns haven’t changed.
  • … XNodes are clarified that they only apply to XNodes
  • … Map patterns are extended by this proposal.
  • … Array and JNode patterns are new.
• MK: Sequence patterns aren’t a top level kind of pattern, but they’re used by several others.
  • … They match a sequence; the empty sequence of an item type plus an occurrence indicator.
• MK: Map patterns change primarily by the addition of ,* to say that it’s extensible.
  • … For example, {} matches an empty map, {*} matches any map, {"first", "last"} matches a map containing first and last, {"first", "last", *} matches a map that contains first and last and maybe other things.
  • … The key has to be a constant
  • … And there are a number of examples, including {"elements": **, *} (!!!)

MK observes that some of these ideas come from a white boarding exercise that we did in Prague.

• MK: Array patterns is just array with a sequence pattern inside.
  • … Every member has to match the sequence pattern, you can’t match heterogenous arrays.
• MK: Finally, JNode patterns match JNodes.
  • … You specify a selector part (the key part) and then a pattern to match the value part.
  • … And then there are examples.

There is an editorial error, the list of 1 to 7 after the green box of examples should be removed.

• MK: The section on default priorities is changed, but just to ensure that every kind of rule has a default priority.
• JLO: I like it. Remind me why the tilde character is necessary.
• MK: The tilde character says that the pattern matches a type. It turns any type into a pattern. That’s not new.
• JLO: Is it true for arrays as well?
• MK: It’s somewhat confusing because there are both types and patterns for arrays and they’re not the same.
  • … I was half thinking that I might try to reduce some of the scope for using types as patterns to avoid some of the overlap.
  • … But at the moment, it is the way it is.
• AP: You mentioned that you can’t match heterogenous arrays? Can’t you use union types?
• MK: Yes, but you can’t say the first member is a string and the second is something else.
• JK: One suggestion on sequence patterns, perhaps we should name that “pattern sequences” to avoid ambiguity over the name. (In case we do want to match sequences in the future.)

Proposal: accept this PR.

Accepted.

MK to remove the errant list and then do the merge.

See PR #2676

• MK: This was CG’s suggestion that I implemented.
  • … Though it may have been something I suggested long ago!
• MK: This PR adds a trace clause to FLWOR expressions as an intermediate clause.
  • … It takes an ExprSingle as the argument; the expression is evaluated and some record of its value should be presented.
  • … It has no effects on the results of the expression.
  • … If an error occurs, report it on the trace output destination and otherwise ignore it
• MK: There’s an example. With some advice to implementors and users.

Proposal: accept this PR.

Accepted.

See PR #2671

• MK: This was an oversight; we dropped it from one function but not another.
  • … By and large, the XML can contain the number in the original format, so there’s no great need for the number parser.
  • … It was there primarily for compatibility with parse-json, but we’ve dropped it there.

Proposal: accept this PR.

Accepted.

See PR #2670

• MK: This arose from all the discussions about build date time records and whether absent fields should be absent or empty.
  • … For many purposes, you don’t care. If you’re looking at the results of a test case, you might want deep-equal to treat them as the same.
• MK: It’s a new option ignore-empty-entries on fn:deep-equal.
  • … It effects how you compare maps. It defines a “significant” entry to simplify the prose.
• WP: Have you consider instead or in addition a function that would scrub a map, removing all the empty entries?
• MK: No, I didn’t think of that. There are ways of filtering with the map-filter function.
• WP: I guess this is a nice to have.
• JLO: I like this. Why don’t we make this true by default?
• NW: I’d say “because it hasn’t historically been this way.”

Some discussion of the circumstances under which the distinction might be significant.

• MK: I think that’s going too far.

Proposal: accept this PR.

Accepted.

See PR #2667

• MK: No one, including me, has ever been very happy with the get() expression in selectors.
  • … It was original designed for selecting keys where the key might not be a string or might contain spaces.
• MK: Mostly, we just replace that with new syntax.
  • … Hopefully the meaning of ancestor::{$name} is clear.
• MK: We rewrite the rules for evaluating slash expressions, mostly for editorial clarity.
  • … The XNodes and JNodes cases are now separated.
  • … For JNodes, the semantics of nodes vs atomic items differ so that atomics select keys with that value.
• MK: The grammar now adds EnclosedExpr to the right hand side of NodeTest
  • … The EnclosedExpr is typically used to select a member.
  • … The get option of a selector is replaced by the EnclosedExpr.
  • … The get() was more constrained syntactically than an EnclosedExpr.
• MK: The expression must match the name of an XNode or JNode.
  • … Multiple values can appear in the enclosed expression, selecting all the matches.
• MK: The rest is just changing examples.
• JWL: Two things. When you’re talking about evaluating E1/E2; it might be worth noting that you can only get maps and arrays in that sequence at the top level. You can have XNodes below maps and arrays but not the other way around.
  • … When you’re doing a computed name, you could do that in patterns as well, couldn’t you?
• MK: Not with the syntax at the moment.
• JWL: You can have a let inside a predicate so you can work up and down.
• MK: But at the level of /a/b/c, the syntax isn’t there yet.
• JLO: It feels natural with the curly braces. I can select XNodes also, yes?
• MK: Yes.
• JLO: For the note that you can never have JNodes selected from inside an XNode, that might change.
• MK: Not directly. You can do it indirectly, if you have a node inside a map and you select the map and then select the entry, that result is going to be JNode containing an XNode.
  • … There are places where that will automatically be dereferenced.
  • … Some things are going to work and others aren’t.
• JLO: I really like that I can write a/3.

Some discussion of the presence (or absence) of the tilde in path expressions.

Proposal: accept this PR.

Accepted.

See PR #2589

• MK: I think this one isn’t as scary as you might imagine.
  • … 12.7.7 Streamability of Pipeline Expressions is new.
  • … There are three rules based on the cardinality of the left hand operand.

Proposal: accept this PR.

Accepted.