- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 12 May 2026 17:48:56 +0100
- To: public-xslt-40@w3.org
Hello,
Here are today’s minutes:
https://qt4cg.org/meeting/minutes/2026/05-12.html
QT4 CG Meeting 165 Minutes 2026-05-12
[1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
Pull Requests
Table of Contents
* [6]Summary of new and continuing actions [0/2]
* [7]Draft Minutes
* [8]1. Administrivia
+ [9]1.1. Roll call [8/10]
+ [10]1.2. Accept the agenda
+ [11]1.3. Approve minutes of the previous meeting
+ [12]1.4. Next meeting
+ [13]1.5. Review of open action items [1/3]
+ [14]1.6. Review of open pull requests and issues
o [15]1.6.1. Blocked
o [16]1.6.2. Merge without discussion
* [17]2. Technical agenda
+ [18]2.1. PR #2616: 2613b Additional notes, examples, and
clarifications for xsl:array-member
+ [19]2.2. PR #2611: 2598 New function fn:regex
+ [20]2.3. PR #2609: QT4CG-156-03 Revise text on JNode identity
+ [21]2.4. PR #2603: 2602 EXPath file and binary modules as
optional features
+ [22]2.5. PR #2601: 2568 Error code changes for dateTime
functions
+ [23]2.6. PR #2596: 2580 Map patterns
+ [24]2.7. PR #2566: 1979 Records with type annotations
+ [25]2.8. PR #2594: 2389 Adaptive Serialization: more freedom
* [26]3. Any other business
Summary of new and continuing actions [0/2]
* [ ] QT4CG-143-02: MK to try to recover the ability to extract
formal equivalences into tests
* [ ] QT4CG-160-02: NW to think about how to promote the dated drafts
for broader community feedback.
Draft Minutes
1. Administrivia
1.1. Roll call [8/10]
Regrets: AP, JLO.
* [X] David J Birnbaum (DB)
* [X] Reece Dunn (RD)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [x:25-]
* [X] Michael Kay (MK)
* [ ] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [ ] Alan Painter (AP)
* [X] Wendell Piez (WP)
* [X] Norm Tovey-Walsh (NW) Scribe. Chair.
1.2. Accept the agenda
JK points out that PR #2595 was accepted last week. I've removed it
from today's agenda.
Proposal: Accept [27]the agenda, as amended.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [28]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 19 May 2026.
Possible regrets from DB.
1.5. Review of open action items [1/3]
* [ ] QT4CG-143-02: MK to try to recover the ability to extract
formal equivalences into tests
* [ ] QT4CG-160-02: NW to think about how to promote the dated drafts
for broader community feedback.
* [X] QT4CG-165-01: NW to follow-up with the generator authors and
schedule another discussion
+ NW sent email today
1.6. Review of open pull requests and issues
This section summarizes all of the issues and pull requests that need
to be resolved before we can finish. See [29]Technical Agenda below for
the focus of this meeting.
1.6.1. Blocked
The following PRs are open but have merge conflicts or comments which
suggest they aren't ready for action.
* PR [30]#2019: 1776: XSLT template rules for maps and array
* PR [31]#2071: 77c deep update
* PR [32]#2160: 2073 data model changes for JNodes and Sequences
* PR [33]#2247: 716 Deferred Evaluation in XPath - the f:generator
record
* PR [34]#2350: 708 An alternative proposal for generators
1.6.2. Merge without discussion
The following PRs are editorial, small, or otherwise appeared to be
uncontroversial when the agenda was prepared. The chairs propose that
these can be merged without discussion. If you think discussion is
necessary, please say so.
* PR [35]#2623: 2621 Add reference to post-process option
* PR [36]#2622: 2612 fn:char: Support \b and \f
* PR [37]#2618: 2585 (part) Clarify error handling on
date/time/duration arithmetic
Proposal: accept without discussion.
Accepted.
2. Technical agenda
2.1. PR #2616: 2613b Additional notes, examples, and clarifications for
xsl:array-member
See PR [38]#2616
* MK: There is a technical change here.
+ ... One of the comments last week asked about what would
happen if you put array-member in place of sequence in the
example.
+ ... They'd be double wrapped
+ ... So I've changed the specification so that it doesn't
double wrap them, or raise an error.
* JWL: There's a bit about never using array member in a for each;
would that raise a static error?
* MK: That's a good question. Yes, you'd get XTDE4060. It could be
detected statically sometimes.
+ We could possibly make that a type error.
Proposal: accept this PR.
Accepted.
2.2. PR #2611: 2598 New function fn:regex
See PR [39]#2611
Not ready for discussion.
2.3. PR #2609: QT4CG-156-03 Revise text on JNode identity
See PR [40]#2609
* MK: I think there's a cosmetic change in XQuery, but the
substantive changes is in F&O.
+ ... Yes.
* MK: In F&O, we add introductory material to 16.1, Functions on
JNodes
+ ... The text on fn:jtree changes. In particular, the second
paragraph about identity.
+ ... The concept of identity for maps and arrays is only weakly
defined.
+ ... I've simplified some of the examples.
Proposal: accept this PR.
Accepted.
2.4. PR #2603: 2602 EXPath file and binary modules as optional features
See PR [41]#2603
* MK: There are details about what the implications are.
* MK: In XQuery,
+ ... In conformance, we list the details about what it means to
support the Binary Library Feature
+ ... (Or what it means not to).
+ ... For the File Library Feature, the requirement is imposed
that you provide implementation-defined mechanism related to
side-effects.
Proposal: accept this PR.
Accepted.
2.5. PR #2601: 2568 Error code changes for dateTime functions
See PR [42]#2601
* NW: I think Sheila has done what we asked.
Proposal: accept this PR.
Accepted.
2.6. PR #2596: 2580 Map patterns
See PR [43]#2596
MK introduces the PR; this is a slight revision of what we had before.
* MK: I see this as a step in a pipeline; the project of applying
template rules to maps and arrays in trees is currently incomplete.
We still need to define builtin templates, modes, and such.
+ ... But we need better match patterns for them.
+ ... Matching maps by type annotations means that we need
additonal mechanisms to match structurally.
* MK: It's a new top-level pattern, MapPattern.
+ ... (The expansion in 6.3.2.4 is too verbose; but that's
editorial.)
MK describes the syntax and walks through the following examples.
* MK: The default priority rules are pretty basic and follows the
general principles.
* JWL: In the first example, how would write the pattern that I
wanted something to be either the first or the last?
* MK: You can't do that directly.
* JWL: The keys can be QNames, could you end up with a QName with a
colon in it?
Some discussion of wether or not the colon could be ambiguous.
Consensus: no.
* MK: The usual problem with colons, that you need to follow them
with a space, will apply.
* JK: I think the PR is great, I wonder how record types will be
invoked in the match pattern.
* MK: Yes, that's a separate topic because records are changing and
I'm trying to keep things separate.
+ ... This is one step along the way.
Proposal: accept this PR.
Accepted.
2.7. PR #2566: 1979 Records with type annotations
See PR [44]#2566
* MK: This has been reviewed before; this is a response to comments.
* MK: It's a data model change, so we'll start there and then go to
the XQuery spec.
* MK: In the data model,
+ ... A record is now a distinguished thing. It's a map that is
constrained by a record type definition.
+ ... In the type hierarchy, record is a subtype of map.
+ ... A record has a type annotation.
+ ... Section 8.3 outlines what a record is. Two new accessors:
o ... record-get-value accessor
o ... record-replace-value accessor
+ ... The key thing about replace value is that it constructs a
new instance of the record type with the same type annotation,
so the replacement may not change the type.
* MK: In XQuery,
+ ... We reintroduce syntax for AnyRecordType.
+ ... Record types are defined in the appropriate section.
+ ... The whole purpose of the proposal is to enable stronger
type checking.
+ ... At the time of writing, it's not required that an instance
of check must have the same type annotation. It's structural.
o ... I'm not sure if that's going to be the final state of
affairs.
o ... If we want to do a check on the type annotation, we
need to introduce derivation so that one record type can
extend another.
+ ... For the moment, this is workable but we could go further.
+ ... Records are created by coercing a map to the required
record type.
+ ... Record types may be anonymous or named, for useful
reasons.
There's an open editorial issue that we need an appendix that lists all
the builtin record types.
* MK: Using a record type in a signature causes coercion to happen.
* MK: Record are maps, so they're also function items. We explain the
signature of the corresponding function item.
* MK: Some slight changes in the subtyping rules.
+ ... Fields are no longer optional or mandatory, but they can
be empty.
* MK: Coercion rules are defined for records.
* MK: There's a new RecordPutExpr, (+:=)
* MK: It's a type error to attempt to access a field that's not part
of the record type.
* MK: There's a new operator +:= that updates a record.
+ ... The +:= operator is type safe.
* MK: Some examples are updated.
* MK: You can declare record types in the prolog.
+ ... It's simplified because we no longer have optional fields;
the constructor functions are much simpler.
* MK: That's basically it, other specs are updated in equivalent
ways.
* CG: Thanks again. I think my comments haven't been incorporated
yet. Could we look at those?
MK agrees to review the comments.
2.8. PR #2594: 2389 Adaptive Serialization: more freedom
See PR [45]#2594
* CG: This basically results from user feedback. It effects the
adaptive serialization method.
* CG: As JSON becomes more common, we regularly encounter numbers
that represented as doubles, so 100 becomes 1E2.
+ ... To make the adaptive serialization more useful, I propose
making some of these more implementation defined.
* CG: The "&" needs to be escaped to "&" in strings for XQuery,
but not for XPath.
* MK: The question is what are we trying to achieve. The reason for
the numeric format had in mind a sort of debugging use case.
+ ... It's intended to signal that it's a double not an integer.
It allows users to tell that it's not an integer. That's
appropriate for some use cases and not others.
+ ... Generally, the whole issue of escaping characters that
might be hard to distinguish is tricky.
+ ... I thought it was a bit odd to escape "&" without also
escaping angle brackets. But I can't give a precise rational.
* RD: The challenge with things like non-breaking space is that it's
used in some cases in French. And it's used in publishing to keep
things together.
* MK: You get non-breaking hyphens as well.
* RD: Also, the familiy character in emojii has a non-breaking space
in the middle. Messing with those can effect rendering.
* CG: What I can add is that in our use cases, we also have a custom
serialization for BaseX. Maybe we shouldn't use adaptive at all. As
MK says, it's difficult to give an answer for every use case.
* RD: With numbers, don't we have the decimal format specifier to
indicate how to format numbers?
* MK: You could add lots of parameters, but it's hard to imagine them
all being used.
* RD: The default should be usable but provide options for users to
override that.
* CG: It can be tricky, because it depends on where you use it, which
is also implementation-dependent.
+ ... You can use it for trace output, but you don't have to,
...
* MK: You can see the output actually being someting interactive,
where it's clickable, or copy-and-pastable.
The current state isn't satisfying.
* CG: What would the drawback be if we made more features
implementation-defined?
* RD: You run into interoperability problems.
* MK: One advantage of making it implementation-defined is that it
discourages people from believing that it's intended to be machine
readable.
+ ... Making it clear that this isn't intended to be consistent.
* CG: Okay, maybe I'll have another try.
* WP: I think the big risk is that people will be surprised by the
changes.
+ ... I think what we've heard is correct, it's not really a
solvable problem in the standards.
CG will make another PR.
3. Any other business
None heard.
References
1. https://qt4cg.org/meeting/minutes/
2. https://qt4cg.org/
3. https://qt4cg.org/dashboard
4. https://github.com/qt4cg/qtspecs/issues
5. https://github.com/qt4cg/qtspecs/pulls
6. https://qt4cg.org/meeting/minutes/2026/05-12.html#new-actions
7. https://qt4cg.org/meeting/minutes/2026/05-12.html#minutes
8. https://qt4cg.org/meeting/minutes/2026/05-12.html#administrivia
9. https://qt4cg.org/meeting/minutes/2026/05-12.html#roll-call
10. https://qt4cg.org/meeting/minutes/2026/05-12.html#agenda
11. https://qt4cg.org/meeting/minutes/2026/05-12.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2026/05-12.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2026/05-12.html#open-actions
14. https://qt4cg.org/meeting/minutes/2026/05-12.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2026/05-12.html#blocked
16. https://qt4cg.org/meeting/minutes/2026/05-12.html#merge-without-discussion
17. https://qt4cg.org/meeting/minutes/2026/05-12.html#technical-agenda
18. https://qt4cg.org/meeting/minutes/2026/05-12.html#pr-2616
19. https://qt4cg.org/meeting/minutes/2026/05-12.html#pr-2611
20. https://qt4cg.org/meeting/minutes/2026/05-12.html#pr-2609
21. https://qt4cg.org/meeting/minutes/2026/05-12.html#pr-2603
22. https://qt4cg.org/meeting/minutes/2026/05-12.html#pr-2601
23. https://qt4cg.org/meeting/minutes/2026/05-12.html#pr-2596
24. https://qt4cg.org/meeting/minutes/2026/05-12.html#pr-2566
25. https://qt4cg.org/meeting/minutes/2026/05-12.html#pr-2594
26. https://qt4cg.org/meeting/minutes/2026/05-12.html#any-other-business
27. https://qt4cg.org/meeting/agenda/2026/05-12.html
28. https://qt4cg.org/meeting/minutes/2026/05-05.html
29. https://qt4cg.org/meeting/minutes/2026/05-12.html#technical-agenda
30. https://qt4cg.org/dashboard/#pr-2019
31. https://qt4cg.org/dashboard/#pr-2071
32. https://qt4cg.org/dashboard/#pr-2160
33. https://qt4cg.org/dashboard/#pr-2247
34. https://qt4cg.org/dashboard/#pr-2350
35. https://qt4cg.org/dashboard/#pr-2623
36. https://qt4cg.org/dashboard/#pr-2622
37. https://qt4cg.org/dashboard/#pr-2618
38. https://qt4cg.org/dashboard/#pr-2616
39. https://qt4cg.org/dashboard/#pr-2611
40. https://qt4cg.org/dashboard/#pr-2609
41. https://qt4cg.org/dashboard/#pr-2603
42. https://qt4cg.org/dashboard/#pr-2601
43. https://qt4cg.org/dashboard/#pr-2596
44. https://qt4cg.org/dashboard/#pr-2566
45. https://qt4cg.org/dashboard/#pr-2594
Be seeing you,
norm
--
Norm Tovey-Walsh
CEO, Saxonica
Received on Tuesday, 12 May 2026 16:49:07 UTC