- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Tue, 19 May 2026 10:36:15 -0700
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
- Message-ID: <CAK4KnZfr5xXDWcotpsNqWZMzWkMmc6EMn2dCVBNjjC+hbs3RZA@mail.gmail.com>
Related to the first item of the discussion: https://www.science.org/content/article/researchers-aim-universal-ai-disclosure-guidelines-devil-details?utm_source=Live+Audience&utm_campaign=26612afd6a-nature-briefing-ai-robotics-20260519&utm_medium=email&utm_term=0_-b08e196e33-49392792 Maybe in the not so distant future there will be clear norms established, when it would be considered natural that everybody is using some form of AI (but taking full personal responsibility for the published work), as today people are using calculators, despite the fact that when calculators first appeared many were concerned that their use would significantly affect and slash mathematical thinking and abilities. Thanks, Dimitre. On Tue, May 19, 2026 at 10:08 AM Norm Tovey-Walsh <norm@saxonica.com> wrote: > 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 > > -- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- Never fight an inanimate object ------------------------------------- To avoid situations in which you might make mistakes may be the biggest mistake of all ------------------------------------ Quality means doing it right when no one is looking. ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play ------------------------------------- To achieve the impossible dream, try going to sleep. ------------------------------------- Facts do not cease to exist because they are ignored. ------------------------------------- Typing monkeys will write all Shakespeare's works in 200yrs.Will they write all patents, too? :) ------------------------------------- Sanity is madness put to good use. ------------------------------------- I finally figured out the only reason to be alive is to enjoy it.
Received on Tuesday, 19 May 2026 17:36:32 UTC