QT4 CG Meeting 151 Minutes 2026-02-03

• [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] 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 10 February 2026.

No regrets heard.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-143-03: JK to look for C14N test suites.
• [ ] QT4CG-144-01: MK to consider if any now lost value comparisons should be added as examples.
• [X] QT4CG-148-02: NW to publish a dated draft after QT4CG-148-01 is complete.
• [ ] QT4CG-149-01: CG to draft a new PR with the common rule note.
• [X] QT4CG-149-02: MK to update the PR #2372 so that the “?” are part of the comment.
• [ ] QT4CG-150-01: NW to ask Jirka for a room at XML Prague for Tuesday/Wednesday
• [ ] QT4CG-150-02: Everyone review the “nice to have” tags and object where they wish
• [ ] QT4CG-150-03: NW to setup an agenda item to review open issues
• [ ] QT4CG-150-04: NW to see about a status update on PR; possibly schedule discussion

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

MK introduces the motivations for the proposal. To make it easier to manage extensible and non-extensible record types without having to create multiple types.

• JWL: Does this mean all record types are extensible?
• MK: No, instance of still checks.
• JWL: So I can other stuff, but when they get passed to a function, it’ll strip out everything that’s not necessary.
• MK: Yes.
• WP: Sounds fine to me; it only applies to built-in record types.
• MK: You can’t define your own extensible record types. You have to pass a map.
• JLO: I’m unconvinced. I fear especially that instance of is failing even though all the keys that should be in there are present.
  • … It will create non-extensible records.
  • … And for serialization, we need extensiblity.
• MK: Yes, it does mean that the option parameters where you want to allow vendor-specific extensions become more difficult.
  • … We pass those as maps.
• JLO: I’d like to see them as extensible records.

MK proposes to review the text and come back to the discussion.

• MK: The main impact is in the XQuery spec.
  • … A record is now just a sequence of field definitions.
  • … We lose a lot of text because we’ve dropped a feature.
  • … Coercion rules discard the additional fields.
  • … That means you can make use of static checking. But it could be done the other way.
  • … All the rules related to extensible record types are dropped.
  • … Constructor functions are considerably simplified
• MK: There are consequence changes in XSLT for pattern matching.
• CG: I really like this proposal. I think there are a lot more ways to enforce type safety.
  • … We’re using records a lot and everytime they’re extensible, you don’t know anything about them.
• RD: I’m happy with this; we can always add extensible records back in if it’s necessary. Worst case, you supply the parameter as a map.
• WP: I see an analogy to schema validation. I think leaving extensible options as maps is fine. I think this is a price worth paying.
• JLO: I’m still not convinced. If both MK and CG are in favor, I’m inclined to go along.
  • … I’d really like to see how we could end up using records for options that will have additional entries.
  • … Could we have vendor-defined records?
• MK: It’s always easier to add a feature than remove one, but more valuable to remove it.
  • … I concede that this loses things, but there were lots of things we had to work out for extensible and non-extensible record types. This is the cleanest solution I could come up with.
• AP: The generators proposal was based on extensible records; but they’d have to be maps, I guess.

Some discussion of how you might make it work; you could have a fixed field whose value is a map. Could this also work for things like serialization?

• MK: We could also try to define a subtyping relationship between two different record types.
• JK: I’m not opposed to simplifications. As a developer, I was looking forward to writing my own extensible record types. What’s the alternative?
• MK: We could look at some type of subtyping relationship. Something that’s not arbitrarily extensible, but more like XSD. But that causes a lot of complexity as well. That would make static error checking harder.
• JK: It would be nice, but I’m in favor of simplification.
• JLO: I see that there’s a way forward and I’m fine.
  • … Why is the order of entries changed in the map to match the order of field declarations?
• MK: It doesn’t have to be. This proposal doesn’t change that; that was already the case.
  • … It just means if you know you have a record, you know the order.
• CG: It also means you can directly reference the offset into records (as an implementor).
• MK: There’s a cost on doing the coercion.
• JWL: To come back on the mark of JLO’s. Remember, there are two sorts of “records”: maps that are records and maps that are just maps.

Proposal: accept this PR.

Accepted.

See PR #2418.

• MK: This arose from an action or a review.
• MK: It clarifies JSON serialization of numbers, canonically and non-canonically.

Proposal: accept this PR.

Accepted.

See PR #2416.

• MK: This was in response to a Saxon user pointing out that it was quite hard to round a date time to a integer number of seconds.
  • … It’s a general problem that it’s not easy to convert between dateTimes and the numeric values of the components.
• MK: There’s a new dateTime record type and a function to create a dateTime from one of those records.
  • … You have to have one of a specific set of fields.

ACTION QT4CG-151-01: MK to fix the typo in the build-dateTime function.

• MK: I could decide if the extract function should be parts-of-dateTime or parts-from-dateTime. I chose parts-of-dateTime.
• MK: The use case becomes decode, round, and encode again.
• CG: Have you seen my comment with the solution to use the round function?
• MK: Yes. There are ways to do it, but this seemed more natural and general.
• WP: I think this is way better than the alternatives.
• JLO: Will this make it easier to get to seconds-since-epoch.
  • … Could we do “to-dateTime-record”?
• MK: Names are always tricky.
• NW: I think time divided by 1 second is the quick and dirty way to get seconds from epoch.
• JWL: Is there any argument for doing the same for durations?
• MK: Yes. I decided not to do both at once.
• RD: Didn’t we have a proposal a while back to do this?
• MK: Early on I had a parts function that decomposed several data types. That got lost.

Proposal: accept this PR.

Accepted.

See PR #2410.

• MK: Debbie Lockett pointed out that we had an old version of fn:highest that didn’t make any sense.
• MK: This PR reinstates fn:highest along the lines of fn:lowest.

Proposal: accept this PR.

Accepted.

See PR #2404.

ACTION QT4CG-151-02: NW to generate compiled schema.

Proposal: accept this PR.

Accepted.

See PR #2409.

• MK: This is a trivial change proposed by CG.
  • … It just changes the serialized form.
• CG: It just seems like what users might expect.

Proposal: accept this PR.

Accepted.

See PR #2419.

• MK: This is substantive but it’s following a well trodden path; we’ve done this for the doc function before. The only complication is that the document() function already had a second argument. So I did the choice trick.

MK reviews the proposal text.

Proposal: accept this PR.

Accepted.

ACTION QT4CG-151-03: NW to investigate why records are formatted incorrectly in XSLT

See PR #2423.

• MK: This isn’t changing the spec; it’s removing an incompatibility that we introduced.
• MK: A simplfied stylesheet used to have an implicit match pattern of “/” which meant it could only match a document node and couldn’t, for example, process JSON.
  • … This documents the incompatibilities.

Proposal: accept this PR.

Accepted.

See PR #2428.

• MK: This deletes the section on embeded stylesheet modules.
  • … It doesn’t remove the feature. We say elsewhere that a stylesheet may be embedded.
  • … All this does is cut out advice and guidance; partly because no one uses them and they’re tricky to use.
  • … You get all sorts of tricky issues related to ID values, fragment identifiers, etc.
• MK: It also removes a reference to the xml-stylesheet processing instruction which has never been part of XSLT.
• RD: If a processor doesn’t need to support this, how do you specify it?
• MK: With some kind of API.

Some discussion of what it means to have a stylesheet embedded in another document and what sorts of APIs you might need.

Proposal: accept this PR.

Accepted.