QT4 CG Meeting 171 Minutes 2026-07-07

• [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)
• [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 14 July.

JWL gives regrets; WP gives potential 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-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-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
• [ ] 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 #2649

• CG: We’ve talked about this before.

CG walks through the improved prose.

• CG: I added a rule and changed recurse and filter accordingly.
• MK: The file path returned is the one provided, not a normalized path.
• CG: This was always underspecified, but BaseX and Saxon do it differently.

Proposal: Accept this PR.

Accepted.

See PR #2717

Another one we discussed previously.

• CG: On the question of ASCII for group names, that’s all that many implementations support.
• CG: Should we allow positions and name groups?
  • … My argument was that we can use predicates. I’ve added examples.
• JLO: I’d like to know why you didn’t select the //group.
• CG: In this case I wanted to make it more explcit.
• JLO: I think this example would be even nicer if you make one of the fields optional, so the numbers change on each example.
• JK: I like the PR, the predicate tip is really nice.
  • … To add to JLO’s example, it would be nice to see a mixture of named and non-named groups.

Proposal: Accept this PR.

Accepted.

See PR #2753

• CG: This one is really editorial; we have a stable but it was only mentioned in the options. The rules didn’t say what the other options were.

Proposal: Accept this PR.

Accepted.

See PR #2755

• CG: This was a longstanding issue. We changed the rules for the bin and other file functions. Now we have the same rules for encoding text everywhere. I’ve aligned fn:unparsed-text with the other functions.
  • … This may require a few examples to be revised.
• JWL: The XPath spec now refers to the bin: spec for something fairly important. I suppose we’ve done it for file already in a similar way?
• CG: We had this example before, it has been this way before.
• JWL: It’s a case where we have a fundamental concept that’s defined by an optional part of the spec.
• MK: Yes, but you can still refer to the specification.

Proposal: Accept this PR.

Accepted.

See PR #2754

• CG: This changes the *-doc functions so that the rules reflect the code that’s used in each case.

Proposal: Accept this PR.

Accepted.

See PR #2756

• CG: The only question is do we want to keep the large pseudocode example.
• MK: I’m inclined to take it out.
• CG: I’d prefer to drop it.
• RD: Is it adequately explained in the rules?
• CG/MK: Yes.
• CG: I also updated the examples.

Proposal: Accept this PR.

Accepted.

See PR #2764

• CG: This is a note on possible implementation optimization.
  • … This is about early exits from a fold if a fixed point occurs.
• MK: Doesn’t that example depend on all the values being positive?
• CG: Yes, but it will work in this example.
• JLO: To me, the wording is precise enough.
  • … What’s interesting is, what if there’s a trace or some other side effect?
• CG: We say if it’s deterministic in this case, so trace is excluded.

Proposal: Accept this PR.

Accepted.

See PR #2747

• CG: I checked this with Gunther and he agrees this should be sound.
  • … You can now use ? without parenthesis in more places.
• MK: I was slightly surprised how little text is needed to describe the semantics, but I couldn’t see anything missing.
• JLO: We had several occasions where we had to distinguish between XNodes and JNodes, is this the same here?
• CG: JNodes aren’t relevant here, it’s just about the parsing.
• MK: What about deduplication and document order
• CG: It will just make (a/b)?c and a/b?c the same.
• MK: If two things in b both reference an element node c, do you get two copies or only one?
• CG: I think both of these will behave the same way.

Some further discussion of the semantics of the expression.

• MK: I’ll think about it.

Proposal: Accept this PR.

Accepted.

See PR #2752

• CG: This adds documentary variable names to higher order functions. I made them gray. They’re like comments, you can’t type them in or use them. But it’s useful to refer to them in the prose.
• CG: This simplifies the prose for a lot of functions.
• JLO: I like it very much, the only question I have is why is it $acc instead of $accumulator. (in fn:fold-left).
• CG: I tried to use short names so that it fits in the tableaux better.
• JWL: It’s worth stating somewhere that this doesn’t mean they can be called by keyword!
• CG: I think it’s mentioned somewhere.
• MK: It’s the system calling these functions, not the user.

Proposal: Accept this PR.

Accepted.

See PR #2759

• CG: I was confused because we have declare type declarations in XQuery. We already had constructor functions for some of them.
  • … I made two versions; in one version I added it to the item type declaration section.
  • … It works quite well for enums and choice items.

Proposal: Accept this PR.

Accepted.

See PR #2768

• CG: This issue arose from the new syntax of records that have optional entries and required entries after that.
  • … I was never fond of the construtor functions. I think we should drop them.
• CG: This PR also includes a bunch of syntax fixes.
• CG: You can always coerce a map to the record type and then you’ll get the record.
• MK: When I first looked at this, given the way we’ve defined them, none of them needs a constructor function.
  • … They’re mostly the return types of functions.
  • … At the same time, I’m a bit puzzled by the relationship to the previous proposal that adds constructor functions for named item types.

Some discussion of the status of named item types in the specification.

• MK: At least a couple of them are recursive so I’m not sure how that could work.
  • … It’s a little confusing.
• MK: In the context of this proposal, for all these builtin record types, it makes sense not to have a constructor function.
  • … But I’m not sure where that fits into the general scheme of things?
• NW: Is that a request to wait on this PR?
• MK: I’m not sure.
• JLO: I’m also confused. Adding constructor functions for named record types and then removing them for record types seems inconsistent.
  • … I’d like to throw in: does that limit us for testing those return values?
• CG: I don’t think so because you can always cast a map.
• JLO: Why don’t we want to have constructor functions?
• CG: The problem is that some record types have required items that follow optional items. That’s just too hard.
• MK: I wonder if it makes more sense for the constructor function for a record to take a map as its argument.
• RD: Would make more sense to define the record types in terms of the syntax that we’ve got, rather than saying “here are the rules for builtin records and here are the rules for everything else.”
  • … We could end up in a situation like we have for fn:concat() that has a special syntax just for the specs.
• CG: The syntax we currently use is a syntax that you can also use in writing queries, so there shouldn’t be a difference.
• RD: Whatever behavior that has with respect to builtin functions should apply here.

CG invites suggestions for how to design constructor functions for builtin record types.

See PR #2760

• CG: The question here is how to handle fragment identifiers consistently.
  • … They’re optional in fn:doc
• NW: I think this is the wrong behavior, but that’s not relevant to making it consistent.
• MK: The effect was that a previously a fragment identifier was not allowed, now it’s allowed but implementation defined.
• CG: Correct.
• JK: I like the proposal.
• JLO: I fear that this is an escape hatch to allow all kinds of shenanigans with fragment identifiers.
  • … I’d also be in favor of stronger recommends.

See PR #2766

• CG: My proposal is to change the way destructuring works for recorsds and arrays.
  • … My proposal is to use the lookup syntax rather than map:get for destructuring.

Proposal: Accept this PR.

Accepted.

See PR #2746

• CG: This is preparation for CSV serialization. We had wanted to make different formats by bidirectional. We don’t have a way to serialize CSV only parse it.
• CG: My proposal is to drop the row delimiter. Other languages don’t provide an option to change the row delimiter.
  • … Modern CSV parsers already normalize line endings.
• CG: I think we should rename field-delimitor to separator for consistency.
• RD: Are there any examples of CSV like documents that use the control characters for things like start-of-record, end-of-record.
• CG: We have tests for different row delimiters but we only have them for testing.
• JLO: You mean the control characters “row separator” and “field separator”. I’m surprised they’re not allowed.
• MK: I’m in favor of this simplification.
• JLO: Will this be a thing where we decided this in 2026 and we’ll never go back.
• WP: To JLO’s point, this is about CSV more than it’s about Unicode. The CSV world hasn’t caught up yet.

Proposal: Accept this PR.

Accepted.

• No meeting first week of August, otherwise business as usual.

RD presents his work so far on tokenization.

• NW: Is this intended to be a change to normative prose?
• RD: Yes.