- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 11 Nov 2025 17:32:38 +0000
- To: public-xslt-40@w3.org
Hi folks,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2025/11-11.html
QT4 CG Meeting 141 Minutes 2025-11-11
[1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
Pull Requests
Table of Contents
* [6]Draft Minutes
* [7]Summary of new and continuing actions [0/2]
* [8]1. Administrivia
+ [9]1.1. Roll call [9/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 [1/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. Close without action
* [18]2. Technical agenda
+ [19]2.1. PR #2277: 2195 Editorial Omnibus
+ [20]2.2. PR #2273: 2219 A method can be applied to multiple
maps
+ [21]2.3. PR #2266: 540 system-property equivalent for XQuery
+ [22]2.4. PR #2259: 938 Canonical serialization
+ [23]2.5. PR #2120: 2007 Revised design for xsl:array
* [24]3. Any other business
Draft Minutes
Summary of new and continuing actions [0/2]
* [ ] QT4CG-140-02: MK to add a note about dealing with binary in
parse-cvs and parse-json
* [ ] QT4CG-141-01: MK to follow up on a comment by JWL on #2269
1. Administrivia
1.1. Roll call [9/11]
Regrets: DB
* [ ] 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] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW) Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [25]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [26]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 18 November 2025.
1.5. Review of open action items [1/2]
* [X] QT4CG-140-01: NW to make sure that the new spec is in the
dashboard.
* [ ] QT4CG-140-02: MK to add a note about dealing with binary in
parse-cvs and parse-json
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 [27]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 [28]#2256: 2216 All atomic types become ordered
* PR [29]#2160: 2073 data model changes for JNodes and Sequences
* PR [30]#2124: 573 Functions to Construct Trees
* PR [31]#2071: 77c deep update
* PR [32]#2019: 1776: XSLT template rules for maps and array
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 [33]#2272: 2253 Add examples for Q{uri}prefix:local
* PR [34]#2270: 2267 Fix inconsistency in XQuery unprefixed function
declarations
* PR [35]#2269: 2268 Correct equivalent expression for for-each-pair
Proposal: merge without discussion.
Accepted.
ACTION QT4CG-141-01: MK to follow up on a comment by JWL on #2269
1.6.3. Close without action
It has been proposed that the following issues be closed without
action. If you think discussion is necessary, please say so.
* Issue [36]#2265: XDM 4.0: a question about mutability/immutability
of sequence types
* Issue [37]#2203: Drop XSLT Streaming?
* Issue [38]#1953: Make generation of constructor function for named
record types optional
Proposal: close without further action.
Accepted.
2. Technical agenda
2.1. PR #2277: 2195 Editorial Omnibus
See PR [39]#2277.
* MK: CG has added check boxes; let's merge the changes we've got and
press on.
* CG: Many of the comments refer to typos and don't need much work.
+ ... Some issues need a more thorough review
* MK: Yes, if you find something non-trival, it should probably be an
issue in its own right.
Proposal: accept this PR, but leave the issue open.
Accepted.
2.2. PR #2273: 2219 A method can be applied to multiple maps
See PR [40]#2273.
MK reviews the PR
* MK: I think this PR only points out consequences of the spec as its
written. It doesn't make any changes.
+ ... We want maps and arrays to behave like nodes, so we have
to allow functions to behave that way (because maps and arrays
are functions).
+ ... We also want it to work that way so you don't have to do a
test for empty.
* JWL: The CSV to arrays example uses csv-to-arrays() which produces
a sequence of arrays, which is a sequence of functions, that's
subtle!
* JLO: I'm often using a different form of that, using ? to lookup
something. It fails when we have an empty sequence.
* MK: No, empty maps to empty now.
MK continues the review.
* MK: There was a suggestion that each application of =?> could
return zero or more functions, but I haven't changed that. Each
application must return exactly one, but there can be multiple maps
on the left.
* JWL: You normally expect the context item to be consumed fairly
quickly.
* MK: Yes, but it's okay here because the function doesn't change the
context item.
* CG: I need to think about the last example; on the right there are
function items. Is that okay? Wouldn't they need more parentheses.
* NW: I hate it, I agree we have to do it, but I hate it.
* JLO: The result would be a sequence of all the function calls.
* MK: It's exactly like the first example.
* JLO: I often use the ! operator so that I can return sequences of
stuff.
* JWL: That means you could have maps of dispatch functions to
process bits and pieces, couldn't you?
* MK: Yes, it opens up all sorts of amazing things.
* CG: What about this example:
let $math := { 'n': -123, 'abs': fn { abs(?n) } }
return (
(: X works :) $math ? abs($math),
(: X works :) $math =?> abs(),
(: X works :) $math ? wrong(),
(: X fails :) $math =?> wrong()
)
* CG: I think the last two cases should do the same thing.
+ ... A map can have functions that do or don't require maps as
the first argument.
* MK: Yes. I'd just like to retain a few places where you can get
static errors if you misspell things.
+ ... This is saying methods should work a bit like static
function calls. So there's some chance of producing a static
error.
* JLO: What does "works" mean for $math ? wrong()?
* CG: It returns an empty sequence.
* JLO: I sort of think that shouldn't work, but also why it should.
* CG: The lookup expression is used for many things; if you use it to
call functions, you'll have those challenges. If you're just using
it for lookups, you maybe don't want errors. But it can be
missleading if you're calling functions.
Proposal: accept this PR.
Accepted.
* CG: Can we keep 2219 open then?
2.3. PR #2266: 540 system-property equivalent for XQuery
See PR [41]#2266.
MK introduces the PR.
* MK: I added some magic environment variables.
* NW: Why is this better than fn:system-property()?
* MK: The system property function expects QNames in the XSL
namespace.
+ ... I think that could be terribly confusing.
* NW: Fair enough, I'm not going to lie down in the road over this.
* WP: I guess I have similar concerns to NW.
+ I see the problem with namespaces, but it seems like we should
be doing it the same way.
* MK: I reviewed the list of system properties and some are very
XSLT-specific.
+ ... There are things like the vendor URL that isn't really
sufficient.
Some discussion of the actual list of properties proposed.
* WP: I think my question is about user migration.
* MK: It doesn't take away system property in XSLT.
* JLO: I think a function like this is needed; every processor has a
function that does something like this.
+ ... Why isn't this one function that returns a map?
* MK: Because this is the way the environment variables function
works.
+ ... We'd probably do that differently if we were adding it
today, but I just wanted an incremental change.
+ ... And we could add this to a 3.0 or 3.1 processor without
introducing a non-conformity.
* JLO: I'd be in favor of a system properties function that just did
this new behavior.
* CG: I think I agree with JLO; if we have a custom function, we can
add implementation defined properties.
* RD: Why can't we use system property again?
* MK: It's use of the XSL namespace.
* RD: If we did adopt that function, couldn't we keep them separate.
* MK: It creates a lot of complexity in something like a use-when
attribute, is that in the XSLT context or the XPath context? What
about in xsl:evaluate or in load-query-module.
* MK: Let's see what it looks like if we add a new system-properties
2.4. PR #2259: 938 Canonical serialization
See PR [42]#2259.
* JK: It's not ready to vote on, but I could use some feedback.
+ ... The design choice is to add a new parameter named
canonical that takes yes or no and allows canonicalization on
XML and JSON, but could also be extended to XHTML.
+ ... Most parameters in serialization get suspended if you say
canonical=yes. But what about use-character-maps.
* MK: I think you should. If you canonical, then the output should be
canonical XML rather than something else. And from an
implementation perspective, it's very muddled what order you do
things in them.
* JK: I've written that the substitution occurs much earlier than
C14N.
* MK: But that means you have to literally implement as proposed,
doing a non-canonical serialization and then reparse. And gives
rise to new possible errors.
* NW: You could do the double-parsing by hand if you needed to.
* JK: That'd be similar to Unicode normalization. But the C14N specs
opt out of that. You have to supply that as a parameter.
2.5. PR #2120: 2007 Revised design for xsl:array
See PR [43]#2120.
MK reviews the PR.
* MK: This takes into account some of JK's comments on the previous
proposal.
+ ... It attempts to provide a single instruction that meets all
use cases.
* MK: I've reintroduced xsl:array-member as a sub-instruction
* MK: I start with the use cases...
MK walked through the documented use cases.
* JWL: I'm happy that xsl:array-member is back. It's much clearer.
+ ... If you have an array with a for-each but no select and the
sequence constructor contains multiple xsl:array-member
children, what happens?
* MK: Excellent question. (Reviewing the rules) In that case, it has
no effect. Each evaluation of the sequence constructor gives you
one member.
* JWL: Does that mean xsl:array-member is not permitted when you have
no select?
* MK: I thought about that, but thought maybe a warning was better.
+ ... YOu might be right. The orthogonality isn't perfect.
* JK: I'm also happy to have xsl:array-member back. I think arrays
are more conducive to mapping over XML structures.
+ ... I'd like to see the xsl:array-member with a different
parent.
Proposal: accept this PR.
Accepted.
3. Any other business
Tutorial feedback.
* NW: I thought it was great.
* WP: They did an awesome job. Will the results be published?
* JWL: The notes and slides and workbench should remain available.
* MK: What feedback did you get at the conference?
* JLO: All very positive. And thanks to everyone for the hard work!
* JWL: It was the BaseX fiddle that really made it possible for
people to try things out!
* WP: People were very positive about JNodes.
* CG: I thought it was very informative and helpful.
* JLO: Jirka asked me if we want to do it again at XML Prague.
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/2025/11-11.html#minutes
7. https://qt4cg.org/meeting/minutes/2025/11-11.html#new-actions
8. https://qt4cg.org/meeting/minutes/2025/11-11.html#administrivia
9. https://qt4cg.org/meeting/minutes/2025/11-11.html#roll-call
10. https://qt4cg.org/meeting/minutes/2025/11-11.html#agenda
11. https://qt4cg.org/meeting/minutes/2025/11-11.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2025/11-11.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2025/11-11.html#open-actions
14. https://qt4cg.org/meeting/minutes/2025/11-11.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2025/11-11.html#blocked
16. https://qt4cg.org/meeting/minutes/2025/11-11.html#merge-without-discussion
17. https://qt4cg.org/meeting/minutes/2025/11-11.html#close-without-action
18. https://qt4cg.org/meeting/minutes/2025/11-11.html#technical-agenda
19. https://qt4cg.org/meeting/minutes/2025/11-11.html#pr-2277
20. https://qt4cg.org/meeting/minutes/2025/11-11.html#pr-2273
21. https://qt4cg.org/meeting/minutes/2025/11-11.html#pr-2266
22. https://qt4cg.org/meeting/minutes/2025/11-11.html#pr-2259
23. https://qt4cg.org/meeting/minutes/2025/11-11.html#pr-2120
24. https://qt4cg.org/meeting/minutes/2025/11-11.html#any-other-business
25. https://qt4cg.org/meeting/agenda/2025/10-11.html
26. https://qt4cg.org/meeting/minutes/2025/10-28.html
27. https://qt4cg.org/meeting/minutes/2025/11-11.html#technical-agenda
28. https://qt4cg.org/dashboard/#pr-2256
29. https://qt4cg.org/dashboard/#pr-2160
30. https://qt4cg.org/dashboard/#pr-2124
31. https://qt4cg.org/dashboard/#pr-2071
32. https://qt4cg.org/dashboard/#pr-2019
33. https://qt4cg.org/dashboard/#pr-2272
34. https://qt4cg.org/dashboard/#pr-2270
35. https://qt4cg.org/dashboard/#pr-2269
36. https://github.com/qt4cg/qtspecs/issues/2265
37. https://github.com/qt4cg/qtspecs/issues/2203
38. https://github.com/qt4cg/qtspecs/issues/1953
39. https://qt4cg.org/dashboard/#pr-2277
40. https://qt4cg.org/dashboard/#pr-2273
41. https://qt4cg.org/dashboard/#pr-2266
42. https://qt4cg.org/dashboard/#pr-2259
43. https://qt4cg.org/dashboard/#pr-2120
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 11 November 2025 17:32:44 UTC