- 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