QT4 CG Meeting 172 Minutes 2026-07-14

JWL, BTW, WP give regrets.

• [X] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [ ] John Lumley (JWL)
• [X] Alan Painter (AP)
• [ ] 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 21 July.

No regrets heard

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [X] QT4CG-167-01: DB to write a PR for #2641, comments in CSV
  • Overtaken by events, see #2778.
• [ ] 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 #2784

CG introduces the PR.

• CG: Allows you to pass any atomic, so you can use it to pad numbers.
• MK: I made a comment about atomization; if you supply a node whose typed value is an integer or decimal, you’re going to lose any trailing zeros. I’m not sure that’s intuitive behavior.
• CG: How does fn:string-join handle this?
• MK: Yes, it does have the same problem. But I guess it’s consistent.
• JLO: Is it worth nothing that you shouldn’t allow a zero-width space character.
• NW: I think that’ll just do the thing.
• JK: I proposed changing the key word “fill” to “padding” so that it’s clearly a noun.
• CG: Sounds good to me.
• MK: An observation on the error conditions; I think you’l get a type error if the side is not a valid member of the enum. So the extra error condition isn’t necessary.

Proposal: accept the PR.

CG will make the two fixes suggested and merge the PR.

See PR #2778

MK introduces the PR. It had to be rewritten in the light of other changes to CSV.

MK reviews the new section 17.5.3 Comments.

• MK: I also fixed a bug where we forgot to say that the field delimiter must not be a newline.
• AP: If I want to have the first character in the first column, that I have to quote it?

NW observes that DB is not an “external contributor”! :-)

MK: If you’re going to enable comments, choose a character that doesn’t occur in the data. But yes, you could quote it.

Proposal: accept the PR.

Accepted.

See PR #2777

• MK: The PR extends casts to all the collective data types.
  • … The proposed rules just use cast recursively.
• MK: A CastTarget is expanded to include AnyItemType, TypedArrayType, etc.
  • … There’s a bit of an issue with AnyItemType at the top level, but it’s needed to be consistent with recursion.

MK reviews the rules. They’ve been restructured a bit.

• MK: For backwards compatibility, for casting to list types, we don’t constrain the result by the occurrence indicator.
• MK: There’s one other significant change; we used to say that if the input to castable can’t be atomized, you get an error. Now you get false.
• MK: CG raised a comment: if you have a type for a field in your record that isn’t a valid cast target, then you can’t do the cast at all.
  • … Having one field like that rules the thing out.
  • … I introduced item() to deal with that, but it isn’t an adequate solution.
  • CG’s suggestion seems like a better way forward.

MK to revise resubmit.

See PR #2768

• CG: We discussed this last week and MK provided some feedback.
  • … I’ve tried to ceate a new version. But it’s failing at the moment.
• NW: Try restarting the job?
• CG: I did. Twice. Same fail.
• CG: Maybe it’s better to look at MK’s comment.
• MK: I noticed after making that comment that named item types if they are records do have a constructor function.
  • … I think we need to have another attempt to bring together named item types and named record types.
• CG: We use the record constructor functions a lot for user defined record types.
  • … But that doesn’t mean it needs to stay that way.
• MK: I’m not suggesting removing them, but …

Let’s do some more work on this. We’re digging ourselves into a hole here.

See PR #2767

CG reviews the PR.

• CG: How do we tackle the potential backwards incompatibility?
  • … We could say this is changed in 4.0, or we have to try to keep it compatible.
• MK: I’m reasonably comfortable making that incompatibility change.
• NW: That seems fine to me as well.
• JK: In 3.0, 3.1 people thought this was deterministic but it wasn’t.
• MK: I’d have to check to be sure.
• JK: That observation might be useful in the backwards-incompatibility note.

Proposal: accept the PR.

Accepted.

See PR #2761

• MK: We had all the required syntax in place to say if declared types were public or private, or whatever.
  • … But we didn’t have any text describing the samantics.
  • … They’re fairly intutive, but …
• MK: One decision that has to be made is, are types “components”.
  • … I decided not to. There’s a lot of stuff about components refering to other components, etc. and that doesn’t apply to types.
• MK: They aren’t components, but they behave a bit like components.
  • … So I slightly fudged it.

MK reviews the semantics in 3.4.7.

• MK: The rules for schema types are generalized accordingly.
• JLO: It wasn’t clear to me what happens if I have a type that is private to my package but I expose a function that returns that type.
• MK: You can still call the function; if the type in question is a choice type, then you can call it with either of the things in the choice.
  • … Even though the name of the choice type is not visible to you.

You can’t see the name, but you can still manipulate it like a record.

Proposal: accept the PR.

Accepted.

See PR #2760

• CG: I think there’s nothing new.

Wait until we’ve discussed #2786, my issue about fragment identifiers.

See PR #2757

• CG: Gunther observed that the rule about unprefixed function calls made the rules about lookup more complex.
  • … I think if the user has defined a default function namespace, we don’t have to do lookup.
• CG: This proposal implements that.

CG reviews the rules proposed.

ACTION QT4CG-172-01: MK to check if the XSLT rules are consistent with the rules in #2757.

Proposal: accept the PR.

Accepted.

See PR #2713

• CG: When you write scripts, you want to declare records without a prefix.
  • … This PR attempts to define rules for that.

CG reviews the rules.

• CG: This would certainly make simple scripts easier to write.
• MK: We’re going for rules that are simple for people who haven’t read them.
  • … Actually understanding these rules is terribly complex.
• JLO: I think this is useful.

Proposal: accept the PR.

Accepted.