- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Tue, 23 Jul 2024 12:10:23 -0700
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
- Message-ID: <CAK4KnZedMD16WmdgwAC1j=fAyRd+uCCZ9ptv04zV_+a9DBTriA@mail.gmail.com>
Hi Norm,
Action: * [ ] QT4CG-087-01: DN to update PR #1228 to reflect MK's
compromise
and update the vulnerabilities
has been fulfilled.
I checked the resulting text and everything is as per the CG decision.
This PR is ready to be merged: https://github.com/qt4cg/qtspecs/pull/1228
Thanks,
Dimitre
On Tue, Jul 23, 2024 at 9:48 AM Norm Tovey-Walsh <norm@saxonica.com> wrote:
> 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 19:10:40 UTC