QT4 CG Meeting 188 Minutes 2026-11-10

Regrets: DB, BTW, NW, WP.

• [ ] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK), Chair
• [X] Michael Kay (MK)
• [ ] Juri Leino (JLO)
• [X] John Lumley (JWL), Scribe
• [X] Alan Painter (AP)
• [ ] Wendell Piez (WP)
• [ ] Bethan Tovey-Walsh (BTW)
• [ ] Norm Tovey-Walsh (NW)

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 17 November.

BTW, WP, DB, AP, JWL give regrets. NW gives tentative regrets.

• [ ] 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-170-01: RD to draft a proposal that attempts to address the lexical issues differently.
• [ ] QT4CG-177-01: NW to put the progress graphs back in the minutes.
• [ ] QT4CG-182-01: NW to review CG’s diff script
• [ ] QT4CG-187-01: MK to elaborate on the proposal in PR #3031

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 #3048.

• MK: Purely editorial, and JK has submitted a couple of additional improvements that haven't been incorporated yet.
  • … I had misread the original, and have now split definitions and subsequent text.
  • … Issues with Jnode expressions which don't have a navigational context.
  • … I will incorporate JK changes before merge

Proposal: accept this PR.

Accepted.

See PR #3046.

• CG: Added fn:update(). MK suggested using keywords to describe the update type.
  • … Quite a few examples to illustrate the different ways.
  • … Hope it is more readable than before.
  • … Should be much easier to see what the updates are across replace/rename/value.. etc..
• MK: I like this and it's much clearer. Less magic and overloading.
  • … I would prefer deletions to be explicit rather than a default.
  • … Suggest a delete operation.
  • … On the XNode side how do you handle namespaces and type annotations?
• CG: Easier than XQuery update, but there may be special cases to work on
• MK: Always return an untyped tree?
• CG: Yes.
• JWL: Can we use a function for rename?
• CG: Yes
• JK: 'before' and 'after' aren't verbs but perhaps 'prepend' and 'append'
• CG: Yes
• MK: What about 'value'? maybe 'replace-value'
• CG: suggests a minor PR afterwards for supplementary changes.

Proposal: accept this PR.

Accepted.

See PR #3044.

• CG: Suggest adding in the same way as 'cast as'.
  • … For most users this may be irrelevant, but better for explicit control.
• MK: Have you thought about precedence - it might be rather arbitrary as
  • … it is unlikely for them to be mixed.
• JWL: Would it confuse and introduce errors for normal users?

(Some discussion - not really)

• MK: probably only really used for coercion to a record.

Proposal: accept this PR.

Accepted.

See PR #3042.

• MK: All in F&O. Attempts to improve discourse on determinism. Need to get the rules straight. Some text has moved around as well. I shifted the new material to a new area, and the diff reflects transpositions. A function cannot be determined statically to be deterministic, because of options.
  • … Diffs mask a lot of movement around the section.
  • … Options on functions make the determination of determinisim more delicate.
  • … Mainly just changing order and giving better definition
• CG: Would need to repeat the determination of this for all the functions?
• MK: This is in the fuzzy ground between normative and non-normative.
  • … Intended for highly technical users.

Proposal: accept this PR.

Accepted.

See PR #3039.

• MK: The keyword %static wasn't a good reflection of what it is in OO languages.
  • … So suggests %fixed, and similar for XSLT (e.g. nothing to do with static variables).

Proposal: accept this PR.

Accepted.

See PR #3037.

• CG: Labelled records allow us to add 'extends' to give us some single-path inheritance.
  • … We might also allow a 'final' declaration to prevent further extension.
• MK: Does this work with the integrity constraints? So you can add additional constraints.
• CG: Yes

(Some confusion about some of the PR not showing in diff)

• MK: Does this change the rules for lookup?
• CG: No (based on the dynamic lookup)
• JWL: is this a bit of a Pandora's box into full OO?
• CG: Liam has made some suggestions. We might want to look at some limited extensions.
  • … We have restricted ourselves. JLO had some concerns, which this perhaps closes.
• MK: takes us from a stable point to a new stable point.

Proposal: accept this PR.

Accepted.

See PR #3031.

• MK: There was a useful discussion on this last week.
  • … Came to the conclusion that a lot of these could be done by casting to a top-level type

(Effectively a sort of 'schema'?)

• MK: Going to drop this one and replace with something different in the future.

Proposal: close this PR without merging it.

Accepted.

See PR #2998.

• MK: Done a revision but not sure it built correctly.
  • … Went through some sections.
  • … Error codes can be masked by an implementation for security concerns,
  • … and supression of error catching.
  • … Defined 'security-sensitive' property for functions.
  • … Quite a lot of definitional and explanatory text.

ACTION QT4CG-188-01: NW to assist in the merge of PR #2998

Proposal: accept this PR.

Accepted.