- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 01 Sep 2026 18:15:08 +0100
- To: public-xslt-40@w3.org
Hello,
Here are the minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2026/09-01.html
QT4 CG Meeting 178 Minutes 2026-09-01
[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/7]
* [7]Draft Minutes
* [8]1. Administrivia
+ [9]1.1. Roll call [10/11]
+ [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 [3/9]
+ [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. PR #2768: 2740 Drop constructor functions from
built-in records
+ [20]2.2. PR #2789: 2787 XQuery changes to merge declare record
and declare type
+ [21]2.3. PR #2795: 2338 Nomenclature: node(), gnode(), xnode()
+ [22]2.4. PR #2796: 2352 Trusted execution: clarifications
* [23]3. Any other business
Summary of new and continuing actions [0/7]
* [ ] 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-167-09: NW to close all "nice to have" issues at the end
of October if they haven't progressed
* [ ] QT4CG-170-01: RD to draft a proposal that attempts to address
the lexical issues differently.
* [ ] QT4CG-176-01: NW to see about improving the linking for record
types.
* [ ] QT4CG-177-01: NW to put the progress graphs back in the
agendas.
* [ ] QT4CG-178-01: CG to review the functx library for uses of
node()
Draft Minutes
1. Administrivia
1.1. Roll call [10/11]
* [X] David J Birnbaum (DB)
* [X] Reece Dunn (RD)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:07-]
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [X] Alan Painter (AP)
* [X] Wendell Piez (WP)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW) Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [24]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [25]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 8 September.
AP gives regrets for 8 and 15 September.
1.5. Review of open action items [3/9]
* [ ] QT4CG-143-02: MK to try to recover the ability to extract
formal equivalences into tests
* [X] QT4CG-167-05: MK to write a proposal to change #2393 so the
functions return JNodes
+ Competed by PR #2814
* [ ] QT4CG-167-07: NW to review tests for interpolated strings with
edge cases in mind
* [ ] QT4CG-167-09: NW to close all "nice to have" issues at the end
of October if they haven't progressed
* [ ] QT4CG-170-01: RD to draft a proposal that attempts to address
the lexical issues differently.
* [X] QT4CG-174-01: MK to make an issue or otherwise address CG's
comments on #2734.
+ Raised in issue #2819, resoved by PR #2856
* [ ] QT4CG-176-01: NW to see about improving the linking for record
types.
* [X] QT4CG-176-02: MK to refine the strip-space option so that it
takes account of historical defaults.
+ Created issue #2883
* [ ] QT4CG-177-01: NW to put the progress graphs back in the
agendas.
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 [26]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 [27]#2760: 2521 URIs: unify handling of fragment identifiers
* PR [28]#2350: 708 An alternative proposal for generators
* PR [29]#2247: 716 Deferred Evaluation in XPath - the f:generator
record
* PR [30]#2071: 77c deep update
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 [31]#2880: Some XSLT proofreading errors
* PR [32]#2877: 2827 Editorial Notes (August 2026 edition)
* PR [33]#2871: 2813 [XSLT] Reorganise sections 25 and 26
* PR [34]#2870: 2837 Corrections to schema for XSLT 4.0
* PR [35]#2865: Updated: 2863 Records: drop outdated extensible and
required attributes
Proposal: Merge without discussion,.
Accepted.
1.6.3. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [36]#2881: 2873 fn:update: another attempt
* PR [37]#2878: 2073 JNodes and Sequences
* PR [38]#2875: 2874 Formal equivalencies: bugs
* PR [39]#2871: 2813 [XSLT] Reorganise sections 25 and 26
* PR [40]#2870: 2837 Corrections to schema for XSLT 4.0
* PR [41]#2869: 2820 Revise cast expressions to avoid the need for
occurrence indicators
* PR [42]#2868: 2867 fn:current everywhere
* PR [43]#2862: 2861 Clarify CSV serialization edge cases
* PR [44]#2831: 2809 fn:deep-equal, debug option: nondeterminism
* PR [45]#2815: 2567 Extended and restricted record types
* PR [46]#2797: 2699 fn:element-to-map: validation
* PR [47]#2796: 2352 Trusted execution: clarifications
* PR [48]#2795: 2338 Nomenclature: node(), gnode(), xnode()
* PR [49]#2789: 2787 XQuery changes to merge declare record and
declare type
* PR [50]#2768: 2740 Drop constructor functions from built-in records
2. Technical agenda
2.1. PR #2768: 2740 Drop constructor functions from built-in records
See PR [51]#2768
CG summarizes the PR.
* CG: We've looked at this already. It fixes a couple of minor
issues, and it drops the constructor functions.
+ ... The type definitions are changed.
+ ... Constructor functions are excluded for predefined named
types.
+ ... You can still get one by coercing a map to a record.
* RD: Would cast as work as well?
* MK: I think it will once another proposal has been accepted. But
casting to records is not currently status quo, but it's coming.
* JLO: Constructor functions are optional, are there any that still
exist?
* CG: All built-in records don't have constructor functions, but
user-defined records will.
+ ... There are other PRs that make other suggesions.
+ ... Many people will never know that the built in record types
exist.
* JLO: I can just pass in the map and it'll be coerced?
* CG: Yes.
Proposal: accept this PR.
Accepted.
2.2. PR #2789: 2787 XQuery changes to merge declare record and declare type
See PR [52]#2789
MK introduces the PR.
* MK: This is all in XQuery; there's an associated set of XSLT
changes that follow this very closely. They'll follow if the idea
is acceptable.
+ ... Background: you can currently declare a record type using
declare record or declare type.
+ ... There are some differences, recursive definitions and
constructor functions, for example.
+ ... At the very least, we should make the two thing synonyms.
+ ... But what I'm proposing is to drop declare record and
putting all the functionality in declare type.
* MK: There are some changes to constants that get mixed in. The
default value for a record had to be a constant, but it's now
fairly irrelevant to this proposal.
+ ... A couple of meta symbols are defined explicilty and an
empty sequence can be explicit.
* MK: A FieldDecl within a record type always allows an initializer.
* MK: Default values for fields are described. (Section 3.2.8.3.1)
+ ... Default values are particularly useful when you're
defining a record that contain methods.
+ ... A ConstantExpr is just an ExprSingle with some special
semantic constraints.
* MK: Recursive record types are now down with declare type rather
than declare record.
+ The examples are changed.
* MK: The coercion rules for coercing a map to a record include a
special rule for default values that are inline function
expressions.
+ ... You must use the default in the case of a method; the map
you're converting can't override that method.
* MK: The item type declaration acquires the with constructor to
construct the item type.
+ ... The default is that you don't get one.
* MK: The section on item type declarations gets some new text about
records.
+ ... You can have constructor functions for generalized atomic
types, for example unions.
* MK: There's a new section on using methods in records.
+ ... Largely existing text moved to a new place, but you have
declare type as record.
* MK: The section on amed record types disappears.
* JWL: If I had a record type which had a field that was a function
but it wasn't to be treated as a method, and I have a default value
for that, does that imply I can't overwrite it?
* MK: You can still do a map put to change it.
* JWL: But not in the constructor.
* MK: Not if you've defined it as an inline function.
* JWL: It concerns me that there doesn't seem to be any way to say
there's a field that is a function but isn't method.
* MK: The workaround is to define it by hand in a user-defined
function. It biases the syntax towards functions are treated as
methods.
* JWL: I'll have to think about it some more.
* JLO: There's a lot of good things in there. The ConstantExpr can no
longer reference user defined functions?
* MK: It might be over-severe as a rection. I was trying to find
something similar to static expressions in XSLT. I've tried to
define constraints so that the default value can always be computed
at compile time.
+ ... The default value will always be the same and you know
what it is at compile time.
* JLO: I don't see how I can create my own record type when I can't
use my own user defined functions to initialize them.
+ ... That's too limiting.
* MK: The aim is to keep defaults simple. The other question is
aligning it with the rules for default values for function
parameters.
+ ... We have a slightly different set of constraints there.
* MK: The big problem is, what should be the evaluation context for
these default values? The declaration can appear in an as clause
and one approach would have been to say you can only have an
initializer if it's appearing in a named declaration on the top
level
+ ... Then you could constrain it like we do for defaults for
user-defined functions.
+ ... The difference with record declarations is that they
aren't necessarily global; that opens questions about what
happens if they refere to variables, etc.
+ ... This is trying to make it draconian first to avoid edge
cases.
* MK: The other avenue I considered was only allowing an initializer
if it was a named record type declaration.
* JLO: The rules now state that a coercing from a map that has a
function that's the same as a method will just be replaced by the
method. Is there no error?
* MK: We could possibly have an error if you try to override the
value of a method.
* JLO: I think that would make sense.
* RD: On the boolean constants, the way that they're specified, they
don't have the function namespace qualifier.
* MK: That's not actually new. It's not changed by this proposal.
* CG: We introduced this for annotations.
Some discussion of the contexts in which you can use true() and
false().
* MK: It's the literal sequence of characters, rather than a
pseudo-function call.
* RD: Does that cause ambiguities?
* MK: No, because they don't appear where you expect an expression.
* RD: It would be nice if you could specify them with fn:true() or
the EQName.
* MK: The reason for that is that constants are used in some places
where there isn't a namespace context.
* CG: Personally, I'd be glad to preserve the declare record
declaration. It's already widely used and seems to work well. I
think records are fundamental enough in 4.0 that justify having
their own declarations.
* MK: Would you be happy if it was just a synonym?
* CG: It would be nice if they had all the same rules as function
declarations. But if that's too much, an alias could be sufficient.
When I think of function coercions with the as keyword, I probably
wouldn't think of defining functions inside that construct. I'd use
named records.
+ ... I think record declarations are similar to function
declarations.
+ ... But maybe I'm missing the XPath perspective.
* MK: Declaring them in XPath is another problem.
* CG: Declaring record types with out the restrictions would be nice.
* RD: If declare record always created a constructor function and
declare item didn't.
* MK: There were other differences.
* RD: But that would make it easy to resolve declare record types as
functions.
* JWL: I'm still bothered by the distinction between functions and
methods.
+ ... If you did a function valued thing that didn't have the
record type as the type of its first argument, it wouldn't be
a method.
+ ... If we could use that test to decide if it should be
overwritten or not, that might fix the problem.
Some discussion of a special syntax for declaring records.
* CG: In that case, you'd probably need to specify the first
parameter being as that type.
MK to consider and revise.
2.3. PR #2795: 2338 Nomenclature: node(), gnode(), xnode()
See PR [53]#2795
CG introduces the PR.
* CG: This was originally MK's idea. It is a mostly mechanical change
to make the gnode() to node() etc.
+ ... I spent a long time, but I can't promise I caught every
change.
+ ... What I didn't change are GNode with capitals, but we don't
have the syntax gnode() as types.
* CG: I tried to avoid doing controversial edits. If we do this, we
may need to consider other changes.
* MK: I've two slight anxieties, not really objections.
+ ... Do we have it right in terms of all the global changes?
+ ... The other anxiety is the effect on existing code.
+ ... If users have declared a parameter as type node() and
their code makes assumptions that it's an XNode but gets
called with something that isn't an XNode, are we creating a
maintenance night mare.
+ ... It's backwards compatible if they don't use any new
features.
* CG: One advantage is that self::node() would have the right
meaning.
+ ... But there could be unexpected consequences.
* RD: I share the same concern as MK. There are cases for things like
the functx library that assume that instance of node() matches XML
nodes.
+ ... Things like that are likely to break.
* CG: They will break if you invoke them with JNodes.
* AP: There's a lot of cognative dissonance at the start. We talk
about whether a node is a GNode and a node() is an XNode.
* JLO: This seems to be radical, and there might be problems, but I'm
in favor.
* CG: I was hesitant at first, but the more I think about it, the
better it seems.
+ ... So far, no one has used maps and arrays in paths. Whenever
you use it, code may break.
* MK: I'm inclined to take the risk.
* RD: It would be worth auditing things like the functx library to
see if there are any breakages.
* CG: I can have a look.
ACTION QT4CG-178-01: CG to review the functx library for uses of node()
* WP: We should ask, but I think the community is going to lean
towards this.
Proposal: accept this PR (reservations notwithstanding).
Accepted.
2.4. PR #2796: 2352 Trusted execution: clarifications
See PR [54]#2796
* CG: We've introduced a trusted keyword, but it's confusing.
* CG: On the one hand we say who is running code, but is the code
trusted?
+ ... The other thing is, what content are you allowed to
retrieve?
* CG: Maybe having two words would be good. I suggest trusted and
trust-external.
* CG: The results are mostly search-and-replace.
CG reviews the changes in the XQuery specification.
* CG: In summary, it's the same as before, but there are now
different names.
* MK: I think this is okay.
* JLO: I think this is good.
* WP: I also like it.
Proposal: accept this PR
Accepted.
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/09-01.html#new-actions
7. https://qt4cg.org/meeting/minutes/2026/09-01.html#minutes
8. https://qt4cg.org/meeting/minutes/2026/09-01.html#administrivia
9. https://qt4cg.org/meeting/minutes/2026/09-01.html#roll-call
10. https://qt4cg.org/meeting/minutes/2026/09-01.html#agenda
11. https://qt4cg.org/meeting/minutes/2026/09-01.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2026/09-01.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2026/09-01.html#open-actions
14. https://qt4cg.org/meeting/minutes/2026/09-01.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2026/09-01.html#blocked
16. https://qt4cg.org/meeting/minutes/2026/09-01.html#merge-without-discussion
17. https://qt4cg.org/meeting/minutes/2026/09-01.html#substantive
18. https://qt4cg.org/meeting/minutes/2026/09-01.html#technical-agenda
19. https://qt4cg.org/meeting/minutes/2026/09-01.html#pr-2768
20. https://qt4cg.org/meeting/minutes/2026/09-01.html#pr-2789
21. https://qt4cg.org/meeting/minutes/2026/09-01.html#pr-2795
22. https://qt4cg.org/meeting/minutes/2026/09-01.html#pr-2796
23. https://qt4cg.org/meeting/minutes/2026/09-01.html#any-other-business
24. https://qt4cg.org/meeting/agenda/2026/09-01.html
25. https://qt4cg.org/meeting/minutes/2026/08-25.html
26. https://qt4cg.org/meeting/minutes/2026/09-01.html#technical-agenda
27. https://qt4cg.org/dashboard/#pr-2760
28. https://qt4cg.org/dashboard/#pr-2350
29. https://qt4cg.org/dashboard/#pr-2247
30. https://qt4cg.org/dashboard/#pr-2071
31. https://qt4cg.org/dashboard/#pr-2880
32. https://qt4cg.org/dashboard/#pr-2877
33. https://qt4cg.org/dashboard/#pr-2871
34. https://qt4cg.org/dashboard/#pr-2870
35. https://qt4cg.org/dashboard/#pr-2865
36. https://qt4cg.org/dashboard/#pr-2881
37. https://qt4cg.org/dashboard/#pr-2878
38. https://qt4cg.org/dashboard/#pr-2875
39. https://qt4cg.org/dashboard/#pr-2871
40. https://qt4cg.org/dashboard/#pr-2870
41. https://qt4cg.org/dashboard/#pr-2869
42. https://qt4cg.org/dashboard/#pr-2868
43. https://qt4cg.org/dashboard/#pr-2862
44. https://qt4cg.org/dashboard/#pr-2831
45. https://qt4cg.org/dashboard/#pr-2815
46. https://qt4cg.org/dashboard/#pr-2797
47. https://qt4cg.org/dashboard/#pr-2796
48. https://qt4cg.org/dashboard/#pr-2795
49. https://qt4cg.org/dashboard/#pr-2789
50. https://qt4cg.org/dashboard/#pr-2768
51. https://qt4cg.org/dashboard/#pr-2768
52. https://qt4cg.org/dashboard/#pr-2789
53. https://qt4cg.org/dashboard/#pr-2795
54. https://qt4cg.org/dashboard/#pr-2796
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 1 September 2026 17:15:16 UTC