- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 19 May 2026 18:08:22 +0100
- To: public-xslt-40@w3.org
Today’s minutes:
https://qt4cg.org/meeting/minutes/2026/05-19.html
QT4 CG Meeting 165 Minutes 2026-05-19
[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/3]
* [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 [0/2]
+ [14]1.6. Review of open pull requests and issues
o [15]1.6.1. Blocked
o [16]1.6.2. Merge without discussion
o [17]1.6.3. Substantive PRs
* [18]2. Technical agenda
+ [19]2.1. Group policy on commecial LLM-generated content
+ [20]2.2. PR #2611: 2598 New function fn:regex
+ [21]2.3. PR #2566: 1979 Records with type annotations
+ [22]2.4. PR #2626: 2625 Make arguments of fn:substring be
xs:numeric
+ [23]2.5. PR #2627: 2624 Change error codes XPTY0019 and -0020
to XPTY0004
* [24]3. Any other business
+ [25]3.1. Planning for the face-to-face
Summary of new and continuing actions [0/3]
* [ ] QT4CG-143-02: MK to try to recover the ability to extract
formal equivalences into tests
* [ ] QT4CG-165-01: NW to attempt to draft an AI policy.
* [ ] QT4CG-165-02: NW to draft an agenda for the face-to-face
meeting
Draft Minutes
1. Administrivia
1.1. Roll call [8/10]
Regrets: DB.
* [ ] David J Birnbaum (DB)
* [ ] 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.
1.2. Accept the agenda
Proposal: Accept [26]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [27]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 26 May 2026.
CG gives regrets for 2, 9, and 16 June.
1.5. Review of open action items [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.
+ Withdrawn.
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 [28]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 [29]#2594: 2389 Adaptive Serialization: more freedom
* PR [30]#2160: 2073 data model changes for JNodes and Sequences
* PR [31]#2071: 77c deep update
* PR [32]#2019: 1776: XSLT template rules for maps and array
* PR [33]#2350: 708 An alternative proposal for generators
* PR [34]#2247: 716 Deferred Evaluation in XPath - the f:generator
record
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]#2640: Remove space in function declaration between EQName &
params
Proposal: Merge without discussion.
Accepted.
1.6.3. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [36]#2019: 1776: XSLT template rules for maps and array
* PR [37]#2566: 1979 Records with type annotations
* PR [38]#2589: 2587 Streamability of context value expressions
* PR [39]#2611: 2598 New function fn:regex
* PR [40]#2626: 2625 Make arguments of fn:substring be xs:numeric
* PR [41]#2627: 2624 Change error codes XPTY0019 and -0020 to
XPTY0004
* PR [42]#2628: 2617 Duration multiplied or divided by number
* PR [43]#2633: 2632-1: fix critical bugs and DTD-validity issues
* PR [44]#2634: 2632-2: fix broken examples in expressions.xml
* PR [45]#2635: 2632-3: typos and grammar
* PR [46]#2636: 2632-4: logic and semantics
* PR [47]#2637: 2632-5: refresh stale 4.0 content
* PR [48]#2638: 2632-6: cross-cutting consistency
2. Technical agenda
2.1. Group policy on commecial LLM-generated content
PRs #2633-#2638 reflect the output of a commercial LLM. The community
group should decide, before discussing these items, what its policy is
going to be on LLM generated content. This is a policy choice that
needs to be made first because accepting them, or not, will establish a
policy.
* NW: I [49]posted my thoughts, I won't read that email.
* AP: I had to read the PRs; I thought it was interesting to see how
detailed they are. There are quite a few corrections. Do we just
throw them away.
* NW: I believe we should reject them.
* CG: I'd be perfectly fine to reject them. I have manually checked
all of the edits and left aside the larger suggestions; I've left
the majority of the text intact. I think it would be okay to use AI
for checking and validating thing. That's what we do in our
company.
* MK: It's a tough one. I think part of it is to do with the fact
that we don't manage our contributors. We don't know what tools
they use. It's not a binary issue. We've historically applied
gradually increasing amounts of automation for quality control. In
a sense this is just the most recent step. If you use Google now
adays, it's using some AI. Stack Overflow has been killed by AI. In
the past, I've used spell checking and grammar checking tools.
Those increasingly have some kind of AI incorporated. Exactly what
that means, I don't know. Sometimes it's just a marketing buzz
word.
+ ... At some level, I think we need to judge a PR by its
content, not by how it was created. Clearly some edits would
be impossible to check, like rewriting the whole specs. But
I'm not greatly concerned about how it was created.
+ ... It's not our job to say what tools you can use.
* JLO: I think a lot of good things already have been said. I agree
with Norm. But I can't control contributions to the open source
projects I work on, so my life is different now.
+ ... I've seen us making great progress even though you have to
be very wary.
* WP: I agree with everything that's been said so far. I think MK
makes good points about enforcability.
+ ... LLMs aren't reproducible, they aren't transparent, they
aren't accountable. What we're faced with is, as a community,
who is standing up for this?
+ ... There's a big difference between specs and software.
+ ... I'd rather work based on criteria in the PR.
* JK: I've said in response to Norm's email that I largly support a
policy that says no to unmediated LLM tickets. I'm less reluctant
to police other people's efforts.
+ ... The question I have is, "if I want to know if we're using
the Oxford comma's, AI tools are the easiest way to do that."
* NW: A policy is something that we agree to uphold; we have to trust
each other to abide by the rules we agree to abide with! My concern
with allowing any form of LLM generated content is that it's the
camel's nose. And I don't want to spend time analyzing
statistically generated plausible text.
* WP: I think what you said is exactly right. But it's a trust issue.
* JLO: I expect anyone to be able to explain what happens in their PR
irrespective of the tool they use. Tools are tools. There's one
little word in your text "commercial" LLMs.
* CG: I've been using a tool that helps German writers write better
English. It's more LLM today than it used to be. But it's helping
me write good text. The question is what should be okay for me to
contribute?
ACTION QT4CG-165-01: NW to attempt to draft an AI policy.
2.2. PR #2611: 2598 New function fn:regex
See PR [50]#2611.
* MK: I did another draft, it's worth taking a look.
MK walks through the changes.
* MK: CG has raised the point that this might be better done with
caching.
+ ... But given that we belief that we do need this kind of
thing, this is an attempt.
+ ... I've changed the examples so that they're clearer.
+ ... There are examples that call matches more than once, one
that uses flags, and other attempts to make illustrative
examples.
* MK: The record type exposes the type and the flags. They're
described in terms of the function.
+ ... If you take the functions out of context, you're off the
reservation.
* AP: Is there any chance this could be called from inside the
xsl:analyze-string instruction?
* MK: That's a really good question!
Proposal: Accept this PR.
Accepted.
2.3. PR #2566: 1979 Records with type annotations
See PR [51]#2566.
* MK: I have done work on this; there have already been comments.
+ ... I did review all of CG's previous comments and I've
attempted to address them; in most cases by changing the spec.
* MK: There are some current comments that I haven't addressed.
MK reviews the changes by looking directly at the commit diffs.
* MK: The constructor is a pseudo-function because it takes a type as
one of its arguments; I've tried to fudge that.
+ ... You take a map as input and a record type and you adjust
the map, returning the record.
+ ... Getting the value from a record is different than getting
it from the map because you raise an error for missing keys.
* MK: I've made the examples clearer.
* MK: Some of the changes here are from the PR that dropped
extensible record types.
* MK: I'm going to have a rethink about how we match against a
partial type, but I think that's a different program of work.
* MK: Coercion is not specifically related to records, but it's not
economically feasible. It has to be a straight instance of test in
the interest of efficiency.
* MK: There's a note that points to map patterns which are sometimes
a better approach.
* CG: I've closed all the comments that I think are resolved. Two are
still open, but I think the're easy.
* MK: The status quo is that lookup expressions and function
invocation throw the type error if the key doesn't exist, but
map:get doesn't.
* CG: It still says that map:get throws a type error.
* CG: The first item in one of the examples is a function when it
should be a map or use the function operator.
* JWL: We're getting into an area where "record" is definitely a very
typed constraint on a map. It might be worthwhile emphasising that
somewhere.
* MK: You can still treat it as a map, but you don't get a record
back if you change it.
* JWL: But if you put...
* MK: If you use map:put, you get back a general map.
* JK: I like the PR, what's missing (or perhaps I missed) is how
default values are expressed in XPath.
* MK: We don`t have a way of creating costructor functions in XPath,
apart from the built in ones. So there's no XPath mechanism for
declaring a named record type.
* JK: Are we going to try to do that?
* MK: It's hard to find the right cutoff point; it would become
XQuery.
* CG: Note to JWL maybe, if you have a record and you do a map:put
and then coerce it (for example in return a type from a function),
so there may be real opportunities for optimization here.
MK would like to merge this and address outstanding comments later.
Proposal: Accept this PR.
Accepted.
2.4. PR #2626: 2625 Make arguments of fn:substring be xs:numeric
See PR [52]#2626.
* MK: I put forward a PR to change fn:subsequence (a while ago) and I
was surprised to discover that failed to do it to fn:substring.
+ ... We've always accepted xs:double, and there are weird
historical reasons for accepting INF.
+ ... But we've always implemented as xs:numeric so it fails a
few tests.
* MK: The change is pretty straightforward, but I did also change
fn:subsequence to bring them in line.
MK notes that there's a cut-and-paste error in fn:subsequence.
* MK: Moving on to fn:substring~...the arguments are now defined as
~xs:numeric.
* JWL: If you're going to do this, do we also want to do it to the
binary functions as well?
* MK: No, they were never xs:double.
* JLO: Why can't we make it xs:integer here?
* MK: If it was integer, the number you supply would have to be an
exact integer. You'd get a compatibility problem for places where
1.001 might be used.
Proposal: Accept this PR.
Accepted.
MK to merge the PR after fixing the obvious cut-and-paste errors.
2.5. PR #2627: 2624 Change error codes XPTY0019 and -0020 to XPTY0004
See PR [53]#2627.
* MK: This arose from Sheila's work on tests that were returning
different error codes than expected.
+ ... XPTY0019 and XPTY0020 have always overlapped. There are
cases where either is allowed.
+ ... And they're type errors so they can be detected
statically.
+ ... So let's just ditch them and use `XPTY0004~
MK reviews the details of the change.
* MK: I've fixed a statement that wasn't technically true.
+ ... The rest of the changes are just changing the error codes.
* NW: Is there any reason to worry about backwards incompatibility in
a try/catch
* MK: The try/catch is going to be unreliable anyway because they
might be caught statically.
+ ... So I think the risk is pretty low.
Proposal: Accept this PR.
Accepted.
3. Any other business
3.1. Planning for the face-to-face
* Expected: AP, MK, NW, JLO, DB
* Triage the issues list
+ NW proposes we need to be agressive about closing issues; we
should warn folks who won't be at the face-to-face.
* Scheduling
+ Call for comments, consultation, drafts, etc.
* Work on big issues while we're together?
+ Use case for JSON transformations would be a good one to
workshop.
+ Another look at trusted execution?
* Plan for a one hour Zoom call at the end of the day if anyone wants
to join remotely for discussion
ACTION QT4CG-165-02: NW to draft an agenda for the face-to-face meeting
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-19.html#new-actions
7. https://qt4cg.org/meeting/minutes/2026/05-19.html#minutes
8. https://qt4cg.org/meeting/minutes/2026/05-19.html#administrivia
9. https://qt4cg.org/meeting/minutes/2026/05-19.html#roll-call
10. https://qt4cg.org/meeting/minutes/2026/05-19.html#agenda
11. https://qt4cg.org/meeting/minutes/2026/05-19.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2026/05-19.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2026/05-19.html#open-actions
14. https://qt4cg.org/meeting/minutes/2026/05-19.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2026/05-19.html#blocked
16. https://qt4cg.org/meeting/minutes/2026/05-19.html#merge-without-discussion
17. https://qt4cg.org/meeting/minutes/2026/05-19.html#substantive
18. https://qt4cg.org/meeting/minutes/2026/05-19.html#technical-agenda
19. https://qt4cg.org/meeting/minutes/2026/05-19.html#llm-generated
20. https://qt4cg.org/meeting/minutes/2026/05-19.html#pr-2611
21. https://qt4cg.org/meeting/minutes/2026/05-19.html#pr-2566
22. https://qt4cg.org/meeting/minutes/2026/05-19.html#pr-2626
23. https://qt4cg.org/meeting/minutes/2026/05-19.html#pr-2627
24. https://qt4cg.org/meeting/minutes/2026/05-19.html#any-other-business
25. https://qt4cg.org/meeting/minutes/2026/05-19.html#h-E77A38B2-3672-45FD-9A23-77885422ABAD
26. https://qt4cg.org/meeting/agenda/2026/05-19.html
27. https://qt4cg.org/meeting/minutes/2026/05-12.html
28. https://qt4cg.org/meeting/minutes/2026/05-19.html#technical-agenda
29. https://qt4cg.org/dashboard/#pr-2594
30. https://qt4cg.org/dashboard/#pr-2160
31. https://qt4cg.org/dashboard/#pr-2071
32. https://qt4cg.org/dashboard/#pr-2019
33. https://qt4cg.org/dashboard/#pr-2350
34. https://qt4cg.org/dashboard/#pr-2247
35. https://qt4cg.org/dashboard/#pr-2640
36. https://qt4cg.org/dashboard/#pr-2019
37. https://qt4cg.org/dashboard/#pr-2566
38. https://qt4cg.org/dashboard/#pr-2589
39. https://qt4cg.org/dashboard/#pr-2611
40. https://qt4cg.org/dashboard/#pr-2626
41. https://qt4cg.org/dashboard/#pr-2627
42. https://qt4cg.org/dashboard/#pr-2628
43. https://qt4cg.org/dashboard/#pr-2633
44. https://qt4cg.org/dashboard/#pr-2634
45. https://qt4cg.org/dashboard/#pr-2635
46. https://qt4cg.org/dashboard/#pr-2636
47. https://qt4cg.org/dashboard/#pr-2637
48. https://qt4cg.org/dashboard/#pr-2638
49. https://lists.w3.org/Archives/Public/public-xslt-40/2026May/0007.html
50. https://qt4cg.org/dashboard/#pr-2611
51. https://qt4cg.org/dashboard/#pr-2566
52. https://qt4cg.org/dashboard/#pr-2626
53. https://qt4cg.org/dashboard/#pr-2627
Be seeing you,
norm
--
Norm Tovey-Walsh
CEO, Saxonica
Received on Tuesday, 19 May 2026 17:08:29 UTC