QT4CG meeting 137 draft minutes, 7 October 2025

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