- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 07 Oct 2025 17:43:01 +0100
- To: public-xslt-40@w3.org
Hello,
Apparently, I failed to email the agenda yesterday. Apologies for that. They’re in the usual place on QT4CG.org. In any eent, here are the draft minutes from today:
https://qt4cg.org/meeting/minutes/2025/10-07.html
QT4 CG Meeting 137 Minutes 2025-10-07
[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/5]
* [8]1. Administrivia
+ [9]1.1. Roll call [7/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 [6/9]
+ [14]1.6. Preparing for public releases
+ [15]1.7. Review of open pull requests and issues
o [16]1.7.1. Blocked
o [17]1.7.2. Merge without discussion
o [18]1.7.3. Close without action
o [19]1.7.4. Substantive PRs
* [20]2. Technical agenda
+ [21]2.1. PR #2218: 986 Numeric Comparisons
+ [22]2.2. PR #2222: 2217 bin:decode-string: Input encoding
+ [23]2.3. PR #2224: 2148 fn:base-uri: Raise error
* [24]3. Update on QT4 presentation at Declarative Amsterdam
* [25]4. Any other business
Draft Minutes
Summary of new and continuing actions [0/5]
* [ ] QT4CG-116-01: Add a specific error code for unsupported options
on doc and doc-available
+ NW to review who this was supposed to be on and if it's been
overtaken by events
* [ ] QT4CG-127-01: NW to diagram the JTree representing arbitrary
XDM content.
* [ ] QT4CG-128-03: NW to compare the file: module against the
equivalent XProc 3.1 steps
* [ ] QT4CG-137-01: NW to make a concrete proposal for tagged drafts
* [ ] QT4CG-137-02: NW to try to review the spec vis-a-vis #2148
1. Administrivia
1.1. Roll call [7/11]
* [ ] 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)
* [ ] Wendell Piez (WP)
* [ ] Ed Porter (EP)
* [ ] Bethan Tovey-Walsh (BTW)
* [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 14 October 2025.
JWL gives probable regrets.
1.5. Review of open action items [6/9]
(Items marked [X] are believed to have been closed via email before
this agenda was posted.)
* [ ] QT4CG-116-01: Add a specific error code for unsupported options
on doc and doc-available
* [X] QT4CG-118-01: MK to make an incorrect type raise an error in
#1906
* [ ] QT4CG-127-01: NW to diagram the JTree representing arbitrary
XDM content.
* [ ] QT4CG-128-03: NW to compare the file: module against the
equivalent XProc 3.1 steps
* [X] QT4CG-131-01: MK to add a non-schema aware result.
* [X] QT4CG-131-02: MK to expand on the $E := <e A="p q r"... example
* [X] QT4CG-131-03: MK to change "invert" to "transpose" in the
matrix example.
* [X] QT4CG-133-01: MK to correct the use of "Expr" in examples for
get()
* [X] QT4CG-135-01: MK to correct attribute rule 5/d to use the
schema component name
1.6. Preparing for public releases
We currently post "latest draft" publications, which change with every
accepted PR, and PR drafts which expire and get deleted after a month
or so. As things become more stable, should we consider publishing
stable, dated drafts?
* Update the status sections to indicate immutable status
* Publish them to a dated URI space, e.g.
/specifications/2025-11-04/...
* Link to (at least the most recent) dated versions from the homepage
Discussion:
* CG: For me, what's important is that things stop changing.
* NW: This is about pointing to something that's stable.
* RD: Is it possible to publish a candidate recommendation.
* NW: No, that's not something we can do.
* JWL: There's an implication that once you've put out a stable
draft; you'd rather not produce backwards compatibility issues.
* JK: Would you adjust things in the test suite?
* NW: I'm not sure we have the manpower for that; but we could
publish a dated test suite.
* JLO: A think a dated draft is counter productive. People will
assume that all of it are stable. It might be more interesting to
label things stable if they're stable.
* RD: The backwards compatibility has been broken in the past at
various stages in the process.
* MK: I don't think this is primarily about stability; it's about
having a version that people can cite so that documentation of a
product can refer to a cited draft.
+ ... Because the spec is changing, you want to be able to refer
to snapshots of it as it was changing.
+ ... At present, there's no record of what has changed.
* JLO: We could use git tags for this purpose.
Straw poll: would you support publishing "tagged draft"
Most in favor.
ACTION: QT4CG-137-01: NW to make a concrete proposal for tagged drafts
1.7. 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.7.1. Blocked
The following PRs are open but have merge conflicts or comments which
suggest they aren't ready for action.
* PR [29]#2124: 573 Functions to Construct Trees
* PR [30]#2120: 2007 Revised design for xsl:array
* PR [31]#2019: 1776: XSLT template rules for maps and array
1.7.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 [32]#2220: QT4CG-131-02 Expand on existing example for
deconstructed variable bindings
Proposal: merge without discussion.
Accepted.
1.7.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 [33]#1787: Sorted maps revisited
* Issue [34]#1153: XSLT: debugging template rule selection
* Issue [35]#75: Support processing HTML 5 template element content
Proposal: close without further action.
Accepted.
1.7.4. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
(Note that the proposed discussion order is different.)
* PR [36]#2232: 1935 Errors from doc-available
* PR [37]#2231: Updated status section for all documents
* PR [38]#2230: 2229 Drop map:keys-where()
* PR [39]#2228: 2012 Define array:sort-with, revise fn:sort-with
* PR [40]#2227: 2079 Allow optional prefix in EQName syntax
* PR [41]#2226: 2186 Change adaptive serialization of JNodes
* PR [42]#2225: 1718 Ordered Maps: positions in callback functions
* PR [43]#2224: 2148 fn:base-uri: Raise error
* PR [44]#2223: 2193 fn:parse-xml, fn:doc: Drop security options
* PR [45]#2222: 2217 bin:decode-string: Input encoding
* PR [46]#2218: 986 Numeric Comparisons
* PR [47]#2213: 2047 External resources and security
* PR [48]#2208: 675 (part) Update XSLT streamability rules
* PR [49]#2205: 2190 Drop binary input for parse-csv and parse-json
* PR [50]#2160: 2073 data model changes for JNodes and Sequences
* PR [51]#2120: 2007 Revised design for xsl:array
* PR [52]#2071: 77c deep update
* PR [53]#2019: 1776: XSLT template rules for maps and array
2. Technical agenda
(Rearranging the order somewhat.)
2.1. PR #2218: 986 Numeric Comparisons
See PR [54]#2218
* MK: The background is that we made numeric comparison transitive in
some places but not everywhere.
+ ... This PR bites the bullet and makes them transitive
everywhere.
* MK: I tried it in a test branch; most of the failures were in
assertions in test cases (doubles compared with decimals).
MK reviews the changes in the draft.
* MK: The rules for general comparisons change so that untyped atomic
values are cast to the type of the other operand. That mitigates
some of the changes.
+ ... Updated appendix H, but it's non-normative.
* MK: In Functions and Operators most of the changes are in how the
functions are defined.
+ ... I plan to do further work to reduce the number of
redirections to get to the actual rules.
* MK: It doesn't change all that much content, but it's certainly a
change that will break a few people's code, but on the whole the
level of impact is bearable.
* RD: In the first section on casting from untyped atomic, should we
mention xs:integer as well as xs:decimal?
* MK: If you have a general comparison to an integer, you cast the
untyped atomic to decimal. So 1.1 cast to decimal is going to be
not equal to the integer 1.
* RD: If you have an integer 1 and an untyped 1...
* MK: Those will be equal because an integer 1 and a decimal 1 are
equal.
+ ... Doubles compare with integers without problems as well.
* JLO: So eq will never change the type, right?
* MK: An eq converts an untyped atomic to a string; never ot a
number.
+ ... But = does convert.
* JLO: Is this op:numeric-equal()?
* MK: Yes.
* JLO: I think this makes sense, but I think it will break a lot of
code.
* MK: I was pleasantly surprised that it didn't break a vast number
of tests.
+ ... Of course, the test suite is completely atypical.
+ ... It's already dicey if doubles are going to compare equal
because of rounding errors.
* CG: I implemented a prototype of this and I was also positively
surprised that there were only a few edge cases that I had to
investigate in detail.
Proposal: accept this PR.
Accepted.
2.2. PR #2222: 2217 bin:decode-string: Input encoding
See PR [55]#2222
CG introduces the PR.
* CG: We should also look at issue #2221; fn:unparsed-text and
bin:decode-string have different rules for input encoding.
Some discussion of the difference between UTF-16, UTF-16le, and
UTF-16be.
* RD: What about UTF-32?
* MK: I don't think we should extend the set of manditory versions.
Some further discussion of the differences.
* CG: I think we should always interpret the byte-order-mark if there
is one.
* MK: One observation is that bin:decode-string can start in the
middle of the string.
+ ... You can't look for a BOM there.
Some discussion of what it means if you start at a continuation byte?
It's currently unspecified.
* NW: The fact that bin:decode-string starts in the middle makes
things hard.
* CG: I think we should always interpret the BOM.
* JWL: Then you have to be able to provide the BOM in the result.
* JLO: Maybe we should say that the caller of bin:decode-string must
always provide the encoding and other necessary features.
+ ... And maybe provide another function to do the heuristics.
* CG: If you specify an encoding, you might still want to skip those
bytes.
+ ... But what does "offset 0" mean then?
* RD: For 0 I think it makes sense for that to be the start of the
file.
* RD: It does make sense to explicitly specify which encoding you
want; in the middle of a string, you don't know if the alternating
00 and ASCII characters are little-endian or big-endian. So I agree
with JLO that we should always pass the encoding.
* JWL: I think this implies that there needs to be another function
that returns a property record of this sort of stuff: there is a
BOM, encoding, etc.
* RD: There is a WHAT-WG encoding specification. Maybe refer to that
or the relevant Unicode specs on byte order marks.
CG will review and make another proposal.
* RD: I think the two functions should be consistent.
* JLO: I'd really like to see the functions.
2.3. PR #2224: 2148 fn:base-uri: Raise error
* CG: The reason for this small PR is a test case where fn:base-uri()
was invoked with an invalid static base URI.
* MK: My only comment is that it seems a bit odd to raise an error on
something that retrieves the URI. If the data model is allowed to
have an invalid URI, it seems odd to report the error when you
retrieve it.
* CG: But when would that happen.
* MK: Data model construction is a bit out of our control, but you
could impose a constraint in the data model to enforce it.
CG reviews the test case, #2148.
* NW: I think the constructor failing would be better.
* JLO: I think the constructor should fail.
ACTION: QT4CG-137-02: NW to try to review the spec vis-a-vis #2148
3. Update on QT4 presentation at Declarative Amsterdam
JWL and JLO described their plans for their tutorial at the Declarative
Amsterdam conference on Thursday afternoon, 6 November 2025.
4. 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/2025/10-07.html#minutes
7. https://qt4cg.org/meeting/minutes/2025/10-07.html#new-actions
8. https://qt4cg.org/meeting/minutes/2025/10-07.html#administrivia
9. https://qt4cg.org/meeting/minutes/2025/10-07.html#roll-call
10. https://qt4cg.org/meeting/minutes/2025/10-07.html#agenda
11. https://qt4cg.org/meeting/minutes/2025/10-07.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2025/10-07.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2025/10-07.html#open-actions
14. https://qt4cg.org/meeting/minutes/2025/10-07.html#stable-drafts
15. https://qt4cg.org/meeting/minutes/2025/10-07.html#open-pull-requests
16. https://qt4cg.org/meeting/minutes/2025/10-07.html#blocked
17. https://qt4cg.org/meeting/minutes/2025/10-07.html#merge-without-discussion
18. https://qt4cg.org/meeting/minutes/2025/10-07.html#close-without-action
19. https://qt4cg.org/meeting/minutes/2025/10-07.html#substantive
20. https://qt4cg.org/meeting/minutes/2025/10-07.html#technical-agenda
21. https://qt4cg.org/meeting/minutes/2025/10-07.html#pr-2218
22. https://qt4cg.org/meeting/minutes/2025/10-07.html#pr-2222
23. https://qt4cg.org/meeting/minutes/2025/10-07.html#pr-2224
24. https://qt4cg.org/meeting/minutes/2025/10-07.html#declarative-amsterdam
25. https://qt4cg.org/meeting/minutes/2025/10-07.html#any-other-business
26. https://qt4cg.org/meeting/agenda/2025/10-07.html
27. https://qt4cg.org/meeting/minutes/2025/09-30.html
28. https://qt4cg.org/meeting/minutes/2025/10-07.html#technical-agenda
29. https://qt4cg.org/dashboard/#pr-2124
30. https://qt4cg.org/dashboard/#pr-2120
31. https://qt4cg.org/dashboard/#pr-2019
32. https://qt4cg.org/dashboard/#pr-2220
33. https://github.com/qt4cg/qtspecs/issues/1787
34. https://github.com/qt4cg/qtspecs/issues/1153
35. https://github.com/qt4cg/qtspecs/issues/75
36. https://qt4cg.org/dashboard/#pr-2232
37. https://qt4cg.org/dashboard/#pr-2231
38. https://qt4cg.org/dashboard/#pr-2230
39. https://qt4cg.org/dashboard/#pr-2228
40. https://qt4cg.org/dashboard/#pr-2227
41. https://qt4cg.org/dashboard/#pr-2226
42. https://qt4cg.org/dashboard/#pr-2225
43. https://qt4cg.org/dashboard/#pr-2224
44. https://qt4cg.org/dashboard/#pr-2223
45. https://qt4cg.org/dashboard/#pr-2222
46. https://qt4cg.org/dashboard/#pr-2218
47. https://qt4cg.org/dashboard/#pr-2213
48. https://qt4cg.org/dashboard/#pr-2208
49. https://qt4cg.org/dashboard/#pr-2205
50. https://qt4cg.org/dashboard/#pr-2160
51. https://qt4cg.org/dashboard/#pr-2120
52. https://qt4cg.org/dashboard/#pr-2071
53. https://qt4cg.org/dashboard/#pr-2019
54. https://qt4cg.org/dashboard/#pr-2218
55. https://qt4cg.org/dashboard/#pr-2222
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 7 October 2025 16:43:07 UTC