QT4 CG Meeting 180 Minutes 2026-09-15

• [X] David J Birnbaum (DB) [:07-]
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:04-]
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [ ] 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 the previous meeting.

Accepted.

The next meeting is planned for 22 September.

No regrets heard.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] 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.
• [X] QT4CG-176-01: NW to see about improving the linking for record types.
  • Overtaken by events
• [ ] QT4CG-177-01: NW to put the progress graphs back in the minutes.
• [ ] QT4CG-179-01: CG to fix the typo “or absent” in 14.6.5.

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

CG introduces the question of +:= as an operator.

• CG: Perhaps we should replace it with a keyword, I proposed put, but that lead to lots of discussion.
• WP: My vote is for but with.
• JK: I do think that an imperative verb would be wrong.
  • … but with retains both the map and the record as direct and indirect objects.
• NW: Does anyone object to but with?

No objection heard.

Proposal: use but with.

CG will update the PR and merge it.

See PR #2905

• CG: I think this is editorial. We have a note about maps and records that would raise a type error.
  • … But there’s nothing in the normative prose that justifies this.
  • … I added the rule because I think the error is reasonable. We have cast as if you really need to drop them.
• MK: I’m ambivalent. The example is fairly persuasive. On the other hand, I worry a little bit about code breaking as you add things.
  • … And I worry a little bit about the interaction with record subtyping.
  • … I’ll go along with it for now.
• JWL: This issue is really tied up with whether records are really hard edged.
  • … I think if we’re going to make them hard edged, we make them hard edged.
  • … You can’t expect things to be silently ignored. Playing in the middle is going to be problematic later.
• RD: Do we still have a syntax to mark a record as extensible?
• MK: No. That’s gone. And so are optional fields.
• JWL: They can be empty, but not optional.
• RD: The interaction with this and the empty fields would be that if the map doesn’t have the key, then the record gets an empty sequence.

Proposal: accept this PR.

Accepted.

See PR #2903

• CG: This one is basically editorial. MK made some comments on the existing rules for element-to-map
• MK: …which arose from new test cases…
• CG: This PR adds new error conditions.
• MK: I did have one comment. In the note that says entries whose keys are not layout, child or type are ignored, but that will make it invalid against the type and it won’t be coerced.
• RD: That has to do with the new casting rules.
• MK: Yes.

Proposal: accept the PR.

Accepted.

CG to delete the offending sentence and merge the PR.

See PR #2899

• MK: This is just filling out in the gory detail about when castable as returns true and what happens when errors occur.

MK walks through the rules.

Proposal: accept the PR.

Accepted.

See PR #2895

• MK: When you load an XQuery module and there are functions with optional parameters, what kind of function do you get back?
• MK: A note has been made normative.
  • … The rule for fn:current is a little bit arbitrary, but I couldn’t think of anything better.

Proposal: accept the PR.

Accepted.

See PR #2886

• CG: This is an older one.
• CG: It goes back to the observation that we’ve defined properties in the F&O spec that depend on the arity of the function.
  • … Default parameters have changed this quite a bit.
• CG: I tried to change the rules so that they depend on the actual input.
  • … There’s a new function properties section in the prolog.
  • … I’ve removed the default properties from each function, they’re defined in the prolog.
  • … There are a lot of changes, but I checked it twice!
• MK: What have you done about the actual markup in the function catalog?

Some discussion of the stylesheet and function catalog changes.

• MK: Good. Thanks. I think the existing spec is inconsistent and this one still is.
  • … All the functions that depend on collations also have a dependency on the static base URI.
  • … I wonder if we could say that if you resolve a relative collation URI then you have a transitive dependency.
• CG: Shall we add it to the edit issue?
• MK: Yes, I think so.
• JWL: Do we have to do the same for the binary and file specs?
• CG: Yes, I’ve done those as well.
• RD: And the functions in the XSLT spec?
• CG: Yes.

Proposal: accept the PR.

Accepted.

CG to fix the merge conflicts and merge the PR.

See PR #2885

• CG: This is mostly about consistency.
• CG: We’ve added more use of restricted subtypes of integer.
  • … We can’t do this for older functions because of backwards incompatibility.
  • … I thought we should try to do this everywhere or stick with the convention of using xs:integer.
  • … I thought it would be better to use xs:integer.
  • … There are many places where you can’t specify the upper bound (radix, 2-36, for example).
• CG: This PR reverts everything to the base types.
  • … In some cases, I relaxed the rules so that out-of-range values return, for example, the empty sequence.
• CG: For unix-datetime, I allow negative values and you can go before 1970-01-01.
• JLO: An interesting change. I’m torn. I like the newer types where they make sense.
  • … But I can see that relaxing the rules is also useful.
  • … But I can put an integer even if I had the tighter typing.
• MK: I’m not going to lie down in the road, but it’s not totally clear to me that this is an improvement.
  • … I like being able to define the type on a function signature more precisely.
  • … In a sense, it gives you a simpler and more consistent implementation in how you reject the values.
  • … You can even use it in type checking if you can work out that something won’t need to be checked.
  • … But it’s a shame that it’s inconsistent. It would be nice to do one thing consistently.
  • … And I accept the point that if there’s a hard upper limit, we can’t do that with types.
  • … I’m not 100% convinced this is an improvement.
• CG: Currently you get different error types; it’s mostly the inconsistency that I find troubling.
  • … We should try to improve that.
• RD: I think it’s still useful to have the types defined where we know the specific bounds.
  • … Like using xs:nonNegativeInteger and we could use xs:short for the Unicode range.
• NW: We don’t limit you to the BMP.
• MK: If the upper limit is three bytes and schema doesn’t have a value for that, putting in an upper bound that isn’t the real upper bound seems a bit odd.
• RD: In that case, would it be more useful to have a specific Unicode type?
  • … Irrespecitve of that, I think it’s somewhat useful to have the more specific types.
  • … With the 3.0 and 3.1 definitions, if we called the functions with say a negative integer value, what happens?
• CG: The existing functions, nothing has changed.
  • … For the new functions, we used some more specific types. And sometimes in other cases we used a specific error message. I think the more specific message is also better than type errors.
• RD: Eve if we did introduce a range type range constraint, then that wouldn’t specifically resolve all of the cases.
• CG: In a function with a partial implementation, there may be other limits as well.
• RD: In that case, we don’t have a specific type corresponding to the XML char construction.
• MK: Correct.

Some discussion of the XS types, there’s byte and short, but there’s no char.

• JWL: It’s a small thing. The ones that resonated with me most were things like replicate. I’ve used it a fair amount. One of the best places is in indentation.
  • … In that particular case, I really want it non-negative because 0 means something, but if I’ve given you a negative number, something has gone wrong.
  • … But that’s just my experience with that use case.
  • … Part of me agrees that it would be nice to keep the restrictions where you can.
• NW: I don’t think there’s consensus to make this change at this time.

See PR #2862

• MK: This is just tidying up some edge cases.
• MK: There’s some prose that’s been reorganized a bit.
  • … There are definitions for input rows and output rows
  • … There’s no change, just establishing some terminology.
• MK: The main change is clarifying the sequence of events when characters go through.
  • … It simplifies character maps, Unicode normalization, and other things.
  • … There is a sequence of independent phases.
• MK: And clarifying what it means when quoting is required.
• CG: Two minor comments. I think if the newline or line-ending parameters is absent, we should use the implementation defined string. It’s what we do elsewhere and it’s what Excel does for CSV output.

We’ll come back to this next week.