QT4 CG Meeting 185 Minutes 2026-10-20

Regrets: NW

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

This meeting record was composed by NW from the minutes provided by JWL and notes from JK.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 3 November.

JWL gives 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

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 #2918
• MK: People about 80% satisfied but there are some issues. The diffs seem a bit iffy for this one The issue really is what the options should be. I've suggested some names for them:
  • recursive: aimed at directories, not relevant to archives.
  • match: to support regex selection, rather than glob
  • file-extensions: a deeper hint for input, such as taking JSON as text rather than parsed
• MK: fn:uri-collection() has a subset of these options.
• JLO: 1. stable is now true() whereas in Prague false() was suggested.
• MK: Perhaps I changed it for consistency
• JLO: my vote would be for false()
• JLO: 2. form needs some closer attention. Perhaps a little stronger wording to clarify the meaning and recommendations for users
• CG: BaseX stable's default value depends on the source. Database is stable. Hard to define defaults at all. We always recurse and look into archives by default. I would prefer not to define defaults. Collection is used in so many use cases. So much depends upon what you do with the function. It would be difficult to agree on defaults. Otherwise the PR is a great start.
• JLO: regarding parsing options (the five options for xml, json, etc.). Is Json lines option available in json-options? CG: currently not. JLe: if I specify media type as Json, the json options should kick in right? MK: there are implementation-define options that can be included for json line processing.
  • … looks fine then.
• JLO: isn't there an argument to make this an options map, so that it's extensible?
• MK: then they are 3 levels deep!

Proposal: merge this PR.

Accepted.

• See #2979
• MK: much commonality between two different proposals, and this is a synthesis. We agree to have two record types, with new names. Lots of detail work on the semantics. One or two inconsistencies that are noted.
  • … Not much detail in the data model about the types. These are left to other specs. It would be nice to have the data model say more about types, but that's another topic.
• MK: xquery/xpath: real material in 3.2.10 record types. Structural record type and labeled record type.
  • … Intent: no extra entries in a structural record. Example at 5.20 needs to be reworked.
  • … Similar things in XSLT but with slightly different syntax.
• CG: our proposals are similar. I still use "structural" but you use "simple" which is a better choice.
• WP: Like this.

Proposal: merge this PR.

Accepted. #2978 is dropped.

(Some disccusion as being better examined and sorted before #2981)

• CG: This PR now summarises all the serialisation parameters
• MK: That is excellent - I hadn't noticed it
• JLO: NW pointed out this was part of #3009 - shouldn't merge both of them
• ACTION: NW to handle the merge complexity

Proposal: merge this PR.

Accepted.

• See #2981
• CG: continuation of previous changes. Can be used for debugging your code, or is a properly adaptive mode, which changes by type. In this PR attempt to separate the two modes. Added an adaptive-mode parameter: typed|readable|binary binary for output of xs:base64binary as true binary rather than text
• JLO: previously adaptive was mostly implementation defined?
• CG: certain parts eg doubles were spec defined. But it now becomes more implementation-dependent
• JWL: binary equivalent to write-binary()?
• CG: in effect yes
• MK: I'm not enthusiastic, but I understand the motivation. I would prefer to avoid adding complexity. It seems a bit XQuery-oriented. I worry about how XSLT users will see it. Another hesitation: I haven't groked what binary output will look like and what it will achieve.
• CG: binary output, in our use cases, we use serialization not only for strings but all sorts of data types. Extension to binary output would be natural for various APIs.
• MK: you think of binary output as designed for other software to consume?
• CG: yes. Our web server does http responses in binary, and here the data, serialized, can be rendered in binary.
• MK: isn't that setting up binary as a competitor to XML or Json as an xchange format?
• CG: it's only representing the individual data. Binary mode does the same as readable, so it could have been a separate parameter.
• JLO: MK raised a good point - the binary mode is unclear. It isn't really adaptive - it is a proper mode for binary data throughout.

Further Work required on this PR