QT4CG meeting 087 draft minutes, 23 July 2024

Hello,

Here are the minutes from today’s meeting. 

   https://qt4cg.org/meeting/minutes/2024/07-23.html

Thank you all! Have a pleasant and relaxing recess! See you in September.

QT4 CG Meeting 087 Minutes 2024-07-23

   [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/4]
     * [8]1. Administrivia
          + [9]1.1. Roll call [11/12]
          + [10]1.2. Accept the agenda
               o [11]1.2.1. Status so far...
          + [12]1.3. Approve minutes of the previous meeting
          + [13]1.4. Next meeting
          + [14]1.5. Review of open action items [0/3]
          + [15]1.6. Review of open pull requests and issues
               o [16]1.6.1. Blocked
               o [17]1.6.2. Merge without discussion
               o [18]1.6.3. Substantive PRs
     * [19]2. Technical Agenda
          + [20]2.1. PR #1263: 1224 Add xsl:accumulator-rule/@priority
            attribute
          + [21]2.2. PR #1331: 1324 Introduce markup for executable specs
          + [22]2.3. PR #1327: 1309 bare brace ambiguities
          + [23]2.4. PR #1333: 1329 Add content option to
            load-xquery-module
          + [24]2.5. PR #1228: - Adding the BLAKE3 hashing algorithm to
            fn:hash
     * [25]3. Any other business
     * [26]4. Adjourned

Draft Minutes

Summary of new and continuing actions [0/4]

     * [ ] 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-02: DN to work with MK to come to agreement on the
       fn:ranks proposal
     * [ ] QT4CG-087-01: DN to update PR #1228 to reflect MK's compromise
       and update the vulnerabilities

1. Administrivia

1.1. Roll call [11/12]

   Regrets: JLO
     * [X] Reece Dunn (RD)
     * [X] Sasha Firsov (SF)
     * [X] Christian Gr¸n (CG)
     * [X] Joel Kalvesmaki (JK)
     * [X] Michael Kay (MK)
     * [ ] Juri Leino (JLO)
     * [X] John Lumley (JWL)
     * [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 [27]the agenda.

   Accepted.

1.2.1. Status so far...

   These charts have been adjusted so they reflect the preceding six
   months of work.

   issues-open-2024-07-23.png

   Figure 1: "Burn down" chart on open issues

   issues-by-spec-2024-07-23.png

   Figure 2: Open issues by specification

   issues-by-type-2024-07-23.png

   Figure 3: Open issues by type

1.3. Approve minutes of the previous meeting

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

   Accepted.

1.4. Next meeting

   This next meeting is planned for 3 September 2024. We're on recess
   until then.

1.5. Review of open action items [0/3]

   (Items marked [X] are believed to have been closed via email before
   this agenda was posted.)
     * [ ] 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-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 [29]#1231: 1193 Parsing Functions: Empty input
     * PR [30]#1227: 150 PR resubmission for fn ranks
     * PR [31]#1062: 150bis - revised proposal for fn:ranks
     * PR [32]#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 [33]#1332: 1317 Fix the record subtyping rules
     * PR [34]#1328: 1326 wording improvements for concat and string-join

   Proposal: merge without discussion.

   Accepted.

1.6.3. Substantive PRs

   The following substantive PRs were open when this agenda was prepared.
     * PR [35]#1333: 1329 Add content option to load-xquery-module
     * PR [36]#1331: 1324 Introduce markup for executable specs
     * PR [37]#1327: 1309 bare brace ambiguities
     * PR [38]#1296: 982 Rewrite of scan-left and scan-right
     * PR [39]#1283: 77b: Update expressions
     * PR [40]#1263: 1224 Add xsl:accumulator-rule/@priority attribute
     * PR [41]#1228: - Adding the BLAKE3 hashing algorithm to fn:hash
     * PR [42]#1209: 1183 Add transient mode and the transient{}
       expression
     * PR [43]#1185: 1179 array:values, map:values -> array:get, map:get
     * PR [44]#832: 77 Lookup returning path selection

2. Technical Agenda

2.1. PR #1263: 1224 Add xsl:accumulator-rule/@priority attribute

   See PR [45]#1263

   Please review the technical discussion [46]from last week. Several
   members requested a week to consider the proposal.
     * JWL: I'm not sure priority is needed.
     * WP: I agree.
     * MK: Fine by me. I've needed it.
     * RD: My understanding of the feature is that it only applies to the
       rules within a section under the accumulator element. Those are
       evaluated in document order, so you can just order them. You can
       use your editor to see the order.

   Proposal: there isn't consensus for this change. Close the PR without
   merging it.

   Accepted.
     * JWL: It might be useful to add a note that explains how you can
       already do this.

2.2. PR #1331: 1324 Introduce markup for executable specs

   See PR [47]#1331.
     * MK: I was inspired by DN's remarks last week that we have examples
       that don't compile.
          + ... We can go beyond that, we can execute the examples and see
            that they produce the correct results.
     * MK: The visible effect is that if there is an executable equivalent
       (for example, fn:for-each), we get a "formal specification" section
       that includes an equivalent formulation of what the function does.
          + ... I've tried to keep those minimal in their syntax so that
            we have a core language that everything else can be built on
            top of.
               o ... For maps and arrays, I've added a set of primitives
                 for maps and arrays to support this approach.

   MK switches to the Data Model
     * MK: For sequences, maps, and arrays, there are a set of primitive
       operations in the Data Model. Everything else can be built on top
       of those primitives. For maps and arrays, everything really is
       built on top of those.
          + ... That all works quite nicely.
          + ... Of course, we could debate what the primitives should be
            but I've tried to keep the set small.

   MK switches back to Functions and Operators
     * MK: The introduction has been edited and the description of the
       formal specification has been added.
          + ... We'll never get formal specs for things like
            format-number, they're just too complicated.
     * MK: All the map and array functions have formal specifications, and
       the operators on sequences do.

   Things in the "formal specification" sections are checked for syntax
   errors and in some cases semantics as well.
     * DN: Thank you, MK. This is a huge step forward. I was expecting to
       see an attribute or something.
     * MK: Yes, let's try to switch over to the markup.

   MK shows some of the markup.
     * MK: The new section is fos:equivalent. The style attribute
       indicates how it's mapped: primitive, XPath expression, etc.
          + ... There's a stylesheet generate-equivalence-tests.xsl that
            generates an XQuery test file that checks the syntax and
            possibly semantics of the equivalent expressions.
          + (MK walks through some more of the XQuery)
     * DN: It's good to have formal definitions. I was expecting to see
       the phrase "executable specification" somewhere. It would be good
       to have it in the text of the spec as well as the markup.
     * MK: The presence of the formal specification section indicates that
       it's executable, otherwise it's absent.
     * JWL: MK, this is building an interpreter.
     * MK: Yes.
     * JWL: I'll see if I can carry on with my iXML grammars in this vein.
     * MK: It would be really nice to do something about the language
       constructs as well, but that's work for another day.
     * MSM: Since MK expressed some hesitence about the name "formal
       specification" some of us have been wondering (in the Zoom chat) if
       "executable description" or "equivalent expression" would be
       better.
          + ... I like RD's suggestion of "reference implementation"
     * MK: I like that too.
     * RD: Could these be extracted separately as well as in the XQuery
       implementation?
          + ... So that implementors can take them and use them if they
            want to?
     * MK: I'm sure it could be done!
     * DN: Everything that we can specify this way we should do so. When
       we have an exectuable specification, it's a test oracle. We should
       mention this in the description of the "formal specification"
       session.
          + ... I think that would simplify the life of implementors and
            users who want to understand their own examples.
     * JWL: I'm not sure it goes as far as an oracle, because we have to
       consider the error cases. The reference implementation doesn't say
       what it's errors are.
     * MK: Yes. I've tagged the reference implementations with an
       attribute to indicate whether or not it covers error behavior.
     * JWL: Can the errors be in the implementation sections as well?
     * MK: Yes, but many are pretty primitive and don't have a lot of
       errors.
     * WP: I like that direction, the other stress point becomes the
       testing. I'd like to echo what DN said, I think this is great work.

   Proposal: merge this PR.

   Accepted.

2.3. PR #1327: 1309 bare brace ambiguities

   See PR [48]#1327.

   MK introduces the PR.
     * MK: We hit a number of issues that could be traced back to the
       introduction of bare brace syntax for map constructors.
          + ... I decided to experiment with restricting the place where
            you can use a bare brace map constructor.

   MK reviews the grammar changes.
     * MK: The result of this change is that you can only use them at a
       fairly high level. They aren't available in ExprSingle any more.
          + ... You can use them in an argument to a function, in a
            sequence concatenation, in a let binding after :=, on the
            right hand side of a : in map value expression, in a square
            array constructor. Basically, the JSON-style syntax for
            constructing maps and arrays.
          + ... But after the return keyword, for example, you have to use
            map { }.
          + ... So you can use it in the "important" contexts but not
            everywhere.
          + ... The rule of thumb is the word map is needed if it follows
            a keyword.
     * MSM: Where have we not replaced ExprSingle with
       StandaloneExpression?
     * MK: After "then" and "else", after "satisfies", after "in", after
       "return".
          + ... That's the one that'll get people most often, after
            "return"
     * MSM: It looks like the rule of thumb holds pretty well. If what
       precedes it is an alphabetic keyword, you need the word "map".
     * MK: After some operators as well, like "+" but you wouldn't want it
       there.
     * RD: This seems like a reasonable, pragmatic compromise.
     * CG: I think you can always use additional parenthesis instead of
       the map keyword.
     * MK: Yes.

   Proposal: accept this PR.

   Accepted.

2.4. PR #1333: 1329 Add content option to load-xquery-module

   See PR [49]#1333.

   MK introduces the PR.
     * MK: This basically lets you load an XQuery module from a string.
          + ... it extends the options available to load-xquery-module so
            you can use a string.

   Proposal: accept this PR.

   Accepted.

2.5. PR #1228: - Adding the BLAKE3 hashing algorithm to fn:hash

   See PR [50]#1228.
     * MK describes his compromise proposal.
     * DN: I fully support this. I think this supports the goal of the PR.
          + ... I have another remark in the current specification. It
            warns about vulnerabilities in only two of the four
            algorithms. I'd like that corrected.

   ACTION QT4CG-087-01: DN to update PR #1228 to reflect MK's compromise
   and update the vulnerabilities

3. Any other business

     * JWL: When we come back, should we have a review of where we are?
     * NW: Yep.

4. Adjourned

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/2024/07-23.html#minutes
   7. https://qt4cg.org/meeting/minutes/2024/07-23.html#new-actions
   8. https://qt4cg.org/meeting/minutes/2024/07-23.html#administrivia
   9. https://qt4cg.org/meeting/minutes/2024/07-23.html#roll-call
  10. https://qt4cg.org/meeting/minutes/2024/07-23.html#agenda
  11. https://qt4cg.org/meeting/minutes/2024/07-23.html#so-far
  12. https://qt4cg.org/meeting/minutes/2024/07-23.html#approve-minutes
  13. https://qt4cg.org/meeting/minutes/2024/07-23.html#next-meeting
  14. https://qt4cg.org/meeting/minutes/2024/07-23.html#open-actions
  15. https://qt4cg.org/meeting/minutes/2024/07-23.html#open-pull-requests
  16. https://qt4cg.org/meeting/minutes/2024/07-23.html#blocked
  17. https://qt4cg.org/meeting/minutes/2024/07-23.html#merge-without-discussion
  18. https://qt4cg.org/meeting/minutes/2024/07-23.html#substantive
  19. https://qt4cg.org/meeting/minutes/2024/07-23.html#technical-agenda
  20. https://qt4cg.org/meeting/minutes/2024/07-23.html#pr-1263
  21. https://qt4cg.org/meeting/minutes/2024/07-23.html#pr-1331
  22. https://qt4cg.org/meeting/minutes/2024/07-23.html#pr-1327
  23. https://qt4cg.org/meeting/minutes/2024/07-23.html#pr-1333
  24. https://qt4cg.org/meeting/minutes/2024/07-23.html#pr-1228
  25. https://qt4cg.org/meeting/minutes/2024/07-23.html#any-other-business
  26. https://qt4cg.org/meeting/minutes/2024/07-23.html#adjourned
  27. https://qt4cg.org/meeting/agenda/2024/07-23.html
  28. https://qt4cg.org/meeting/minutes/2024/07-16.html
  29. https://qt4cg.org/dashboard/#pr-1231
  30. https://qt4cg.org/dashboard/#pr-1227
  31. https://qt4cg.org/dashboard/#pr-1062
  32. https://qt4cg.org/dashboard/#pr-529
  33. https://qt4cg.org/dashboard/#pr-1332
  34. https://qt4cg.org/dashboard/#pr-1328
  35. https://qt4cg.org/dashboard/#pr-1333
  36. https://qt4cg.org/dashboard/#pr-1331
  37. https://qt4cg.org/dashboard/#pr-1327
  38. https://qt4cg.org/dashboard/#pr-1296
  39. https://qt4cg.org/dashboard/#pr-1283
  40. https://qt4cg.org/dashboard/#pr-1263
  41. https://qt4cg.org/dashboard/#pr-1228
  42. https://qt4cg.org/dashboard/#pr-1209
  43. https://qt4cg.org/dashboard/#pr-1185
  44. https://qt4cg.org/dashboard/#pr-832
  45. https://qt4cg.org/dashboard/#pr-1263
  46. https://qt4cg.org/meeting/minutes/2024/07-16.html#pr-1263
  47. https://qt4cg.org/dashboard/#pr-1331
  48. https://qt4cg.org/dashboard/#pr-1327
  49. https://qt4cg.org/dashboard/#pr-1333
  50. https://qt4cg.org/dashboard/#pr-1228

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 23 July 2024 16:47:57 UTC