- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 23 Jul 2024 17:47:50 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2y15sjbrd.fsf@saxonica.com>
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