QT4CG meeting 083 draft minutes, 25 June 2024

Hello,

Here are today’s minutes:

   https://qt4cg.org/meeting/minutes/2024/06-25.html

QT4 CG Meeting 083 Minutes 2024-06-25

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [1/6]
     * [3]1. Administrivia
          + [4]1.1. Roll call [11/12]
          + [5]1.2. Accept the agenda
               o [6]1.2.1. Status so far...
          + [7]1.3. Approve minutes of the previous meeting
          + [8]1.4. Next meeting
          + [9]1.5. Review of open action items [15/18]
          + [10]1.6. Review of open pull requests and issues
               o [11]1.6.1. Blocked
               o [12]1.6.2. Merge without discussion
               o [13]1.6.3. Substantive PRs
     * [14]2. Technical Agenda
          + [15]2.1. PR #1296: 982 Rewrite of scan-left and scan-right
          + [16]2.2. PR #1295: 1096 Redefine array:index-of to use
            deep-equal for comparisons
          + [17]2.3. PR #1294: 46 Add xsl:item and xsl:sequence/@as
          + [18]2.4. PR #1290: Fix keyword tests to treat "fn" =
            "function"
          + [19]2.5. PR #1288: 1287 Define parse-xml error conditions
          + [20]2.6. PR #1286: Updated list of incompatibilities in F+O
          + [21]2.7. PR #1282: Revise fn:invisible-xml
          + [22]2.8. PR #1262: 1160 Add collation-available() function
     * [23]3. Any other business
     * [24]4. Adjourned

   [25]Meeting index / [26]QT4CG.org / [27]Dashboard / [28]GH Issues /
   [29]GH Pull Requests

Draft Minutes

Summary of new and continuing actions [1/6]

     * [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
     * [ ] QT4CG-080-05: NW to add absolute property to the parse-uri
       output
     * [ ] QT4CG-080-07: NW to update the build instructions in the README
     * [X] QT4CG-082-01: JLO to raise an issue about what to do when
       validation is requested but not possible.
          + Overtaken by [30]#1288
     * [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
       fn:ranks proposal
     * [ ] QT4CG-083-01 MK to revise fn:collation-available to address
       multiple usages

1. Administrivia

1.1. Roll call [11/12]

   CG gives regrets.
     * [X] Reece Dunn (RD)
     * [X] Sasha Firsov (SF) [x:10-]
     * [ ] Christian Gr¸n (CG)
     * [X] Joel Kalvesmaki (JK)
     * [X] Michael Kay (MK)
     * [X] Juri Leino (JLO)
     * [X] John Lumley (JLY)
     * [X] Dimitre Novatchev (DN)
     * [X] Wendell Piez (WP)
     * [X] Ed Porter (EP)
     * [X] C. M. Sperberg-McQueen (MSM)
     * [X] Norm Tovey-Walsh (NW). Scribe. Chair.

1.2. Accept the agenda

   Proposal: Accept [31]the agenda.

   Accepted.

1.2.1. Status so far...

   issues-open-2024-06-25.png

   Figure 1: "Burn down" chart on open issues

   issues-by-spec-2024-06-25.png

   Figure 2: Open issues by specification

   issues-by-type-2024-06-25.png

   Figure 3: Open issues by type

1.3. Approve minutes of the previous meeting

   Proposal: Accept [32]the minutes of the previous meeting.

   Accepted.

1.4. Next meeting

   This next meeting is planned for 2 July.

1.5. Review of open action items [15/18]

     * [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
     * [ ] QT4CG-080-05: NW to add absolute property to the parse-uri
       output
     * [ ] QT4CG-080-07: NW to update the build instructions in the README
     * [ ] QT4CG-082-01: JLO to raise an issue about what to do when
       validation is requested but not possible.
     * [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
       fn:ranks proposal

1.6. Review of open pull requests and issues

1.6.1. Blocked

   The following PRs are open but have merge conflicts or comments which
   suggest they aren't ready for action.
     * PR [33]#1297: Minor correction to fn:scan-right - typo
     * PR [34]#1231: 1193 Parsing Functions: Empty input
     * PR [35]#1227: 150 PR resubmission for fn ranks
     * PR [36]#1062: 150bis - revised proposal for fn:ranks
     * PR [37]#832: 77 Lookup returning path selection
     * PR [38]#529: 528 fn:elements-to-maps

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 [39]#1292: Fix issue 1291 (rounding)
     * PR [40]#1255: 1253 whitespace in xsl:switch

   Proposal: Merge without discussion.

   Accepted.

1.6.3. Substantive PRs

   The following substantive PRs were open when this agenda was prepared.
     * PR [41]#1296: 982 Rewrite of scan-left and scan-right
     * PR [42]#1295: 1096 Redefine array:index-of to use deep-equal for
       comparisons
     * PR [43]#1294: 46 Add xsl:item and xsl:sequence/@as
     * PR [44]#1293: 1289 Delete XQuery Appendix J
     * PR [45]#1290: Fix keyword tests to treat "fn" = "function"
     * PR [46]#1288: 1287 Define parse-xml error conditions
     * PR [47]#1286: Updated list of incompatibilities in F+O
     * PR [48]#1283: 77b: Update expressions
     * PR [49]#1282: Revise fn:invisible-xml
     * PR [50]#1266: 1158 Add array mapping operator
     * PR [51]#1265: 1161 Further revision of document-uri constraints
     * PR [52]#1263: 1224 Add xsl:accumulator-rule/@priority attribute
     * PR [53]#1262: 1160 Add collation-available() function
     * PR [54]#1255: 1253 whitespace in xsl:switch
     * PR [55]#1254: 729 Add rules for use of xsi:schemaLocation during
       validation
     * PR [56]#1244: 566-partial Rewrite parse-uri
     * PR [57]#1228: - Adding the BLAKE3 hashing algorithm to fn:hash
     * PR [58]#1209: 1183 Add transient mode and the transient{}
       expression
     * PR [59]#1185: 1179 array:values, map:values -> array:get, map:get

2. Technical Agenda

2.1. PR #1296: 982 Rewrite of scan-left and scan-right

     * PR [60]#1296: 982 Rewrite of scan-left and scan-right
     * MK: DN and I went separate ways, but let's look at the current
       proposal which I revised in light of DN comments. MK: The
       substantive part of the issue is that the two functions were
       inconsistent with other functions wrt the position parameter.
          + ... I tried to add one, and in the process, discovered that
            fold-left and fold-right were specified incorrectly.
          + ... So I took the other approach and removed the position
            argument from all of them.

   MK discovers that the PR doesn't contain the latest version. We'll
   leave it for a week.
     * DN: I applaud the decision to remove the position parameter.

2.2. PR #1295: 1096 Redefine array:index-of to use deep-equal for comparisons

     * PR [61]#1295: 1096 Redefine array:index-of to use deep-equal for
       comparisons
     * MK: This is an issue that I raised. The original topic was that
       array:index-of as an accident of the way it was specified atomized
       one argument but not another. That gave some unexpected behaviors.
          + ... That lead to a long discussion. There was a strong desire
            to have something parallel to sequence indexing.
          + ... The proposal I've come up with is that we define
            array:index-of using fn:deep-equal.
          + ... I'd support deleting the function entirely, but at least
            this is simple and consistent.
     * DN: I'm pleased to see that collation is the last parameter.
       Probably a sequence of collations is necessary. If the member of
       the array contains strings in different collations, then you'll
       need different collations for the comparisons.
     * MK: That sounds pretty radical. I think if you want that degree of
       sophistication, you have to do it by hand.
     * DN: One collation isn't sufficient if you have a sequence of
       strings in different collations.

   Some discussion of whether or not this is a problem that needs to be
   solved.
     * MSM: On the topic of collations of properties of strings; that was
       not only proposed for 2.0, it was also proposed for XSD. The I18N
       group objected strenuously. I didn't find the arguments especially
       persuasive, but the W3C did. It's clear that many people with
       experience in internationalization would object to that. I think we
       shouldn't go there.

   Proposal: Accept this PR.

   Accepted.

2.3. PR #1294: 46 Add xsl:item and xsl:sequence/@as

     * PR [62]#1294: 46 Add xsl:item and xsl:sequence/@as
     * MK: This takes a number of issues raise separately and attempts to
       address them all.
          + ... The xsl:item is designed to avoid the xsl:sequence when
            you know the item is going to be a singleton.
          + ... Adding an as attribute lets you use stronger type checking
            and more self-documenting code.
          + ... The xsl:item instruction must return a single item, not a
            sequence or empty sequence.
     * DN: I thought XSLT 3.0 was already too large. Now I'm seeing
       something that I don't think needs to be done. An item is a kind of
       sequence. Why do we need a separate instruction? There may be
       alternatives, we could add an attribute to xsl:sequence for
       example.
          + ... I think XSLT has become an ocean of different things and
            they aren't totally exclusive. I get lost trying to determine
            which things I should use and when. Are we going to eventually
            get xsl:* everything in the dictionary?
     * MSM: Relating to cardinality, if the difference between item and
       sequence is that item has fixed cardinality, then thinking about
       systems I have used, and the decision about the empty sequence, I
       would like to be able to specify empty-or-a-singleton and
       singleton. I think the as attribute on xsl:sequence would let me do
       that.
     * MK: Yes.
     * MSM: FWIW, I think I'm neutral on whether adding xsl:item is useful
       enough to justify it.
     * JLY: Similar thoughts to MSM. You have a problem that if it might
       be empty, I have to use xsl:sequence. If I know it's exactly one, I
       can use xsl:item. If I know there might be more than one, I have to
       use xsl:sequence again. And you can do it all with xsl:sequence
       using as.
     * MK: Where this is coming from is that people find it more natural
       to write xsl:value-of which has exactly the wrong semantics.
     * JLY: Yes. Maybe getting rid of xsl:value-of would be nice.
     * RD: In terms of cardinality, there are four choices. Could we do
       this with a required attribute.
     * MK: Yes, I thought the same thing, you could add optional=true.
     * RD: It would make sense required by default and sequence optional
       by default. That's probably what most people would want. Does that
       solve the problem?
     * MK: I don't think you need anything on sequence because you can use
       as. You could allow ? on an as attribute on xsl:item.
     * JK: The motivation for as seems to be that anything with a select
       should have an as. What problem are we solving?
     * MK: I must admit, adding as to xsl:sequence which defines the
       result of the expression. At the moment we only have as on places
       where you're defining an API. This does open the way a little bit
       for demanding an as attribute in many more places.
     * RD: How about anywhere there's a select?
     * MK: Well, xsl:attribute and xsl:processing-instruction have a
       select attribute and it would be overkill there.
          + ... An as attribute changes the behavior.
     * MSM: Since I find that the only reason for me not to use as
       whenever I think about it is to delay errors until production! I
       can easily imagine wanting an as attribute on xsl:attribute if I
       want to specify something about the attribute type.
          + ... The same is true of specifying the target of a processing
            instruction.
          + ... The extent to which this might change the behavior could
            be worrisome. I do find something appealing that says if it
            has a select you can have an as. It's a little bit like making
            a particular form of assertion cheap and easy to express.
          + ... If we decide to allow xsl:item to be optional, I really
            hate the idea of having an optional or required attribute. I'd
            much rather have it be a ? in the as.
     * WP: What I'm hearing is that the problem is xsl:value-of which also
       has select. On balance, I think this addresses a very narrow
       concern with some users. I know plenty of people who like
       xsl:sequence and select because of the flexibility.
     * JLY: If you put as on an xsl:item type, then it will be the on as
       attribute that has different semantics. You can't put a + or * in
       those places.
     * NW: We're not coming to consensus here.
     * MK: I could split it. Or we could drop it.
     * MSM: I had the impression that adding as on select had positive to
       neutral reactions and much of the complication was xsl:item.

   Straw poll: separate the proposals or drop the whole thing?

   Separate proposals: 7. Drop: 1. Abstaining: 1.

   MK will revise PR as he thinks most appropriate.

2.4. PR #1290: Fix keyword tests to treat "fn" = "function"

     * PR [63]#1290: Fix keyword tests to treat "fn" = "function"

   Stylesheet only fix. Not discussed. MK: merge it!

2.5. PR #1288: 1287 Define parse-xml error conditions

     * PR [64]#1288: 1287 Define parse-xml error conditions
     * MK introduces the proposed error conditions for parsing XML.
     * JLO: That completes my action! Thank you. I like the dynamic error
       for DTD validation, but I'm wondering why FODC0007 is the same for
       either DTD or XSD validation.

   Some support for having two different error codes.
     * DN: What is the meaning of FODC0008? Is it a GUID or something?
     * MK: No, the form of the error identifiers was introduced by Andrew
       Eisenberg and kept with the IBM tradition of 8 character names.

   Some discussion of the semantics of the names.

   Proposal: Accept this PR with the amendment that there should be two
   different error codes for DTD and Schema validation errors.

   MK to merge after updating.

2.6. PR #1286: Updated list of incompatibilities in F+O

     * PR [65]#1286: Updated list of incompatibilities in F+O
     * MK: We changed the rules on the options parameter. If you use a
       parameter that isn't recognized. That's a backwards
       incompatibility. I added that to the appendix.

   Proposal: accept this PR.

   Accepted.

2.7. PR #1282: Revise fn:invisible-xml

     * PR [66]#1282: Revise fn:invisible-xml
     * NW explains the changes.

   Proposal: Accept this PR.

   Accepted.

2.8. PR #1262: 1160 Add collation-available() function

     * PR [67]#1262: 1160 Add collation-available() function
     * MK: This changes the semantics of fn:collation. It now generates
       the string but the error is raised by fn:collation-available()
          + ... The only interesting thing about fn:collation-available()
            is the usage parameter. There are three different reasons why
            you might want a collation and which collations might be
            available for each reason differs.
     * JLO: I like this. I like the usage parameter. My question is why
       can't I do a collation available for all of them? Suppose I want to
       use all three? Also: where you are using fn:collation-available()
       which usage is there?
     * MK: No fn:collation() just builds the string. This function asks if
       it's usable.
          + ... I guess we could allow a sequence of enums.
     * DN: We need something like union for the different usages. My
       observation was that we probably could just have a single function,
       fn:collation() and have it return an empty sequence if no such
       collation is available.
     * MK: The fn:collation function can only be used to build UCA
       collations, but this function can be applied to any collation.

   Some discussion of the UCA vs. vendor defined collations.
     * JLY: Originally, collation would form the collation and error if it
       coudln't. So the assumption now is that if you run it without
       checking the collection, the error will occur downstream.

   ACTION: QT4CG-083-01 MK to revise fn:collation-available to address
   multiple usages
     * DN: Even if we have usage specified, it doesn't prevent the user
       from using it in another usage. That's probably not something we
       can address statically. That raises questions about the usability
       of the usage parameter.
     * MK: This function doesn't stop any existing code from working, it
       gives the user the ability to avoid the error.

3. Any other business

   None heard.

4. Adjourned

References

   1. https://qt4cg.org/meeting/minutes/2024/06-25.html#minutes
   2. https://qt4cg.org/meeting/minutes/2024/06-25.html#new-actions
   3. https://qt4cg.org/meeting/minutes/2024/06-25.html#administrivia
   4. https://qt4cg.org/meeting/minutes/2024/06-25.html#roll-call
   5. https://qt4cg.org/meeting/minutes/2024/06-25.html#agenda
   6. https://qt4cg.org/meeting/minutes/2024/06-25.html#so-far
   7. https://qt4cg.org/meeting/minutes/2024/06-25.html#approve-minutes
   8. https://qt4cg.org/meeting/minutes/2024/06-25.html#next-meeting
   9. https://qt4cg.org/meeting/minutes/2024/06-25.html#open-actions
  10. https://qt4cg.org/meeting/minutes/2024/06-25.html#open-pull-requests
  11. https://qt4cg.org/meeting/minutes/2024/06-25.html#blocked
  12. https://qt4cg.org/meeting/minutes/2024/06-25.html#merge-without-discussion
  13. https://qt4cg.org/meeting/minutes/2024/06-25.html#substantive
  14. https://qt4cg.org/meeting/minutes/2024/06-25.html#technical-agenda
  15. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1296
  16. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1295
  17. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1294
  18. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1290
  19. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1288
  20. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1286
  21. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1282
  22. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1262
  23. https://qt4cg.org/meeting/minutes/2024/06-25.html#any-other-business
  24. https://qt4cg.org/meeting/minutes/2024/06-25.html#adjourned
  25. https://qt4cg.org/meeting/minutes/
  26. https://qt4cg.org/
  27. https://qt4cg.org/dashboard
  28. https://github.com/qt4cg/qtspecs/issues
  29. https://github.com/qt4cg/qtspecs/pulls
  30. https://qt4cg.org/dashboard/#pr-1288
  31. https://qt4cg.org/meeting/agenda/2024/06-25.html
  32. https://qt4cg.org/meeting/minutes/2024/06-18.html
  33. https://qt4cg.org/dashboard/#pr-1297
  34. https://qt4cg.org/dashboard/#pr-1231
  35. https://qt4cg.org/dashboard/#pr-1227
  36. https://qt4cg.org/dashboard/#pr-1062
  37. https://qt4cg.org/dashboard/#pr-832
  38. https://qt4cg.org/dashboard/#pr-529
  39. https://qt4cg.org/dashboard/#pr-1292
  40. https://qt4cg.org/dashboard/#pr-1255
  41. https://qt4cg.org/dashboard/#pr-1296
  42. https://qt4cg.org/dashboard/#pr-1295
  43. https://qt4cg.org/dashboard/#pr-1294
  44. https://qt4cg.org/dashboard/#pr-1293
  45. https://qt4cg.org/dashboard/#pr-1290
  46. https://qt4cg.org/dashboard/#pr-1288
  47. https://qt4cg.org/dashboard/#pr-1286
  48. https://qt4cg.org/dashboard/#pr-1283
  49. https://qt4cg.org/dashboard/#pr-1282
  50. https://qt4cg.org/dashboard/#pr-1266
  51. https://qt4cg.org/dashboard/#pr-1265
  52. https://qt4cg.org/dashboard/#pr-1263
  53. https://qt4cg.org/dashboard/#pr-1262
  54. https://qt4cg.org/dashboard/#pr-1255
  55. https://qt4cg.org/dashboard/#pr-1254
  56. https://qt4cg.org/dashboard/#pr-1244
  57. https://qt4cg.org/dashboard/#pr-1228
  58. https://qt4cg.org/dashboard/#pr-1209
  59. https://qt4cg.org/dashboard/#pr-1185
  60. https://qt4cg.org/dashboard/#pr-1296
  61. https://qt4cg.org/dashboard/#pr-1295
  62. https://qt4cg.org/dashboard/#pr-1294
  63. https://qt4cg.org/dashboard/#pr-1290
  64. https://qt4cg.org/dashboard/#pr-1288
  65. https://qt4cg.org/dashboard/#pr-1286
  66. https://qt4cg.org/dashboard/#pr-1282
  67. https://qt4cg.org/dashboard/#pr-1262

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 25 June 2024 16:29:37 UTC