QT4 CG Meeting 174 Minutes 2026-07-28

JLO gives regrets.

• [X] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [ ] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [X] Wendell Piez (WP)
• [X] Bethan Tovey-Walsh (BTW)
• [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 11 August. We will not meet on 4 August.

AP gives regrets.

The action item list in the agenda was incorrect.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-167-03: NW to make a PR for #2482, fallback on bin:decode-string
• [ ] QT4CG-167-05: MK to write a proposal to change #2393 so the functions return JNodes
• [ ] 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.

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

• MK: I updated it as requested last week. It’s an error to omit the select attribute if the content is not an array, map, or element.
• WP: So it works like it does now and you can use strings but you have to use select.
• MK: Yes.

Proposal: accept this PR.

Accepted.

See PR #2707

Skip this again this week.

See PR #2719

Resolved and merged.

See PR #2734

• MK: We reviewed an earlier draft, but folks weren’t too happy. So I’ve revised it.
• MK: The background is making expressions like $map/2 work when you’re dealing with JNodes.
  • … The previous proposal said you get the special treatment of child selection only for literals and variable references.
  • … People weren’t too happy with that.
  • … This takes the opposite approach, you get the behavior unless the expression is one of a set of navigation expressions.

MK reviews the definition of navigational steps in the specification.

• MK: For E1/E2, for an XNode, we evaluate it as before.
• MK: For JNodes, we say the results are similar, provided that the steps are navigational.
  • … In call cases, the result will consist of JNodes.
  • … Where E2 is non-navigational, the value of E2 is used as a map key or array subscript.
  • … It’s evaluated with out a context, so it’s an error to refer to the context.
  • … If you want a step that does that, you need to use something else, like !.
  • … This allows $booklist/$category//author/1/"last name".
  • … Then we provide an analogy to make it clear what the semantics mean.
• MK: Essentially, navigational expressions are ones that depend on the focus, but that doesn’t generalize to all the function calls.
• MK: There’s a lack of referential transparency, but it does what you think it will if you don’t think too hard.
• JWL: What if you have maps that contain a mixture of maps and XNode trees.
  • … Suppose I want to write an expression that says “find a map entry called “name” which is such and such” and from there, I want to got back up and down into the “tree” entry using XNode matching.
• MK: You can do that, but you have to extract the value out of the JNode.
• JWL: So I get a sequence that comes down to ! that does a jvalue() and then I’m back to XNodes
  • … It might be worth explaining what happens with mixtures.
• CG: I like the proposal. I think it’s a good compromise. I put some comments in the PR.
• MK: Let’s look.
• CG: Do we need to have a sequence of XNodes or JNodes or could they be mixed? I think they could be mixed.
• MK: It makes life more and more difficult to decide evaluation statically, but that’s already not always possible.
• CG: The next is that * needs to be replaced with gnode().
• CG: And there are some attributes missing.
• CG: And could we add try/catch?
• MK: I’ll look at those comments.
• WP: I like it. As far as I understand it, it looks workable. It’s going to be a lot easier to understand in the context of data.
  • … Worked examples, especially ones that show gotchas would be very helpful.
  • … Using variables is going to help users; some examples along those lines might be useful.

Some discussion of distinguishing between JNode and XNode with instance of.

Proposal: Accept this PR.

Accepted.

ACTION QT4CG-174-01: MK to make an issue or otherwise address CG’s comments on #2734.

See PR #2739

• MK: This is a simple editorial change.
• MK: Doing this comprehensively is too radical. What I decided to do was get the introduction and terminology sections correct and then try to bring other things in line as best we can.
  • … It makes various changes to the introduction to de-emphasise that it’s an XML transformation language.
• MK: I’ve split the concepts and terminology sections so that conformance and implementation-related things are separate from technical terms.

Proposal: Accept this PR.

Accepted.

See PR #2760

• CG: This is mostly about consistency vs. progress. We want consistent behavior.
  • … To allow or disallow fragment identifiers for all of them.
  • … But #2786 may be blocking.
• MK: Part of my concern is that very often the handling of URIs is handed off to an XML parser or bit of infrastructure, and we don’t always have control over them.
  • … We might not even know which parser is used and it’s not always under our control whether or not things like fragment identifiers are supported.
• NW: Yes, but I think we should be consistent.

See PR #2777

• MK: The motivation was primarily casting to records.
  • … Currently you can only create records using a coercion and that means you have to declare a variable to coerce the type.
  • … Having cast of would make it possible to do it in one step.
  • … Also it allows a stronger coercion (dropping fields, castings integers to decimals, etc.)
• MK: The reason for doing sequences, arrays, and maps, is that records can contain them.
• MK: All the changes are in the grammar, which isn’t ideal, but that’s the way it is.

MK describes the changes to the grammar, starting at CastExpr.

• MK: Casting an array just casts all the individual items.
• MK: Casting a map involves casting all the entries. That’s slightly more complicated because it can cause duplicates to appear.
• MK: Casting to a record type again casts every entry in the record type.
• MK: Casting sequences is distributed through the earlier sections.
• JWL: I think there may need to be some description here about the distinction between Schema lists and sequences.
• MK: Yes, this is the only place we mix schema types and item types and it’s a little awkward.
• JWL: I think you need to say something about casting that specialized form.
• MK: I tried to do that, but I could say more.
• CG: I hadn’t looked at the latest version; do you remember what has changed in the last few days wrt the problem of record constructors may be nested or cannot be cast with the old rules.
• MK: I don’t think I need to do anything to catch up with the fact that records have changed a bit.
  • … Except possibly the rule that when you cast a map to a record type, if an entry isn’t present you get an empty value and an error if that’s not allowed.
  • … If the target of the cast includes functions, you can use them unchanged if they are of the right type, otherwise you always get a type error.
• CG: What about record field initializers?
• MK: They aren’t there yet. That’s a separate PR. I thin when they exist, that will effect the coercion rules.
• AP: This will require an awful lot of test cases!
• CG: I think there are some typos.

Proposal: Accept this PR.

Accepted.

See PR #2788

• MK: CG introduced a PR that allowed ?C to appear as part of a step. But the precedence seemed to be wrong when we looked at the grammar.
  • … Couldn’t find a way of solving that, so this proposes rolling back the change.
• CG: MK is completely right.

Proposal: Accept this PR.

Accepted.

See PR #2789

• MK: The thinking was that there was less and less useful distinction between the two forms.
  • … This is just the XQuery part; I’d expect to do the XSLT part later.
• MK: In the course of this, I also introduced initializers. I felt this needed constraints.
  • … The initializer can only be a function or a constant. To achieve that, I added () to the grammar production Constant.

MK reviews the productions for a TypedRecordType.

• MK: If the initializer is a function, it must be inline and must have an empty closure.
• MK: We have to distinguish named record types rather than unnamed ones.
• MK: The coercion rules for maps to a record type now treat methods specially. The default value takes precedence, basically.
  • … The methods are as defined in the type; you can’t change the area function when you build a new record type.
  • … Or at least it’s more difficult, you have to use assignment or something.
• MK: The section on recursive record types is rewritten, but it isn’t intended to be a substantive change.
• MK: A new section is added about methods in records; largely explanatory.
• MK: And named record types, as such, disappear.
• CG: I’ve already commented on the PR. My concern is that we’d lose some features that we introduced a while ago.
  • … The declare record would be dropped, the initializer function would be optional, and we would lose simple initializers.
• MK: Losing declare record is just syntax in principle, you should be able to do everything with declare type
  • … I think there’s potentially a bit of a problem if you allow arbitrary initial values. It means what appears to be the same type can be a different type, depending on when the initial value expression is evaluated. And what if it has dependencies on types? That introduces an order of evaluation problem.
• MK: I might have been over-restrictive, but I think some restrictions are necessary.

Some discussion of how substantive the change to remove declare record is.

• CG: A restricted declare type and a full declare record declaration for other types might be useful.
• MK: Yes. One reason for declare type is just for semantics.
• MK: It’s a good point about initializers.

MK suggests we review this and come back to it.