- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 28 May 2024 17:22:30 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m28qzt9a9l.fsf@saxonica.com>
Hello,
Here are the minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2024/05-28.html
QT4 CG Meeting 079 Minutes 2024-05-28
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/6]
* [3]1. Administrivia
+ [4]1.1. Roll call [9/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 [3/8]
+ [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. Close without action
* [14]2. Technical Agenda
+ [15]2.1. PR #1237: 1232 consistent rendition of rfc2119 terms
+ [16]2.2. PR #1228: Adding the BLAKE3 hashing algorithm to
fn:hash
+ [17]2.3. PR #1062/#1027/#1227: fn:ranks
+ [18]2.4. PR #1108: 566-partial Describe a less aggressive
%-encoding for fn:build-uri
+ [19]2.5. PR #1185: 1179 array:values, map:values -> array:get,
map:get
+ [20]2.6. Issue #850: fn:parse-html: Finalization
* [21]3. Any other business
* [22]4. Adjourned
[23]Meeting index / [24]QT4CG.org / [25]Dashboard / [26]GH Issues /
[27]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [0/6]
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [ ] QT4CG-077-03: MK to add a note about document order across
documents
* [ ] QT4CG-077-04: MK to review inconsistencies discovered in review
of #1117
* [ ] QT4CG-078-01: MK to make the default for normalize-newlines
backwards compatible.
* [ ] QT4CG-078-02: MK to update the prose of transient{} to use the
word "should".
* [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
1. Administrivia
1.1. Roll call [9/12]
MK gives regrets. JLY gives regrets for this week and next.
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [ ] Michael Kay (MK)
* [ ] Juri Leino (JLO)
* [ ] 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 [28]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2024-05-28.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-05-28.png
Figure 2: Open issues by specification
issues-by-type-2024-05-28.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [29]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is the face-to-face [30]the face-to-face meeting on
4 and 5 June in Prague.
1.5. Review of open action items [3/8]
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [X] QT4CG-071-06: NW to clarify the cases that are distinguished by
the leading empty string in path segments
* [X] QT4CG-072-03: NW to clarify the round-tripping of URIs
* [ ] QT4CG-077-03: MK to add a note about document order across
documents
* [ ] QT4CG-077-04: MK to review inconsistencies discovered in review
of #1117
* [ ] QT4CG-078-01: MK to make the default for normalize-newlines
backwards compatible.
* [ ] QT4CG-078-02: MK to update the prose of transient{} to use the
word "should".
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 [31]#1062: 150bis - revised proposal for fn:ranks
* PR [32]#956: 850-partial Editorial improvements to parse-html()
* PR [33]#921: 920 Allow xsl:break and xsl:next-iteration within
branch of xsl:switch
* PR [34]#871: Action qt4 cg 027 01 next match
* PR [35]#832: 77 Add map:deep-update and array:deep-update
* PR [36]#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 [37]#1243: Change required result of system-property(...version)
(PR [38]#1233 was withdrawn in email discussion after the agenda was
published.)
Proposal: merge without discussion.
Approved.
1.6.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 [39]#1000: XQFO Code in the Rules sections
* Issue [40]#908: Function identity: documentation, nondeterminism
* Issue [41]#894: Errors in forming function items
Proposal: close without further action.
Approved.
2. Technical Agenda
2.1. PR #1237: 1232 consistent rendition of rfc2119 terms
See PR [42]#1237
Proposal: accept this PR.
Accepted.
2.2. PR #1228: Adding the BLAKE3 hashing algorithm to fn:hash
See PR [43]#1228
Straw poll: add BLAKE3? In favor: 4, opposed: 1.
* CG: The question is whether to do exactly this algorithm and not
others?
* DN: My proposal should be regarded in a more general sense. There
are faster algorithms, but many quality and security issues. This
is just my opinion for a modern, better algorithm. Even if we merge
this, let's consider if we want to have at least one modern
algorithm. It doesn't have to be this one.
* RD: I wonder if it would be worth having a review of hasing
algorithms implemented in different languages. XQuery and XSLT
processors are implemented in many languages. Rather than making a
specific decision on this now, say "these are the common algorithms
that are readily available." That lets us choose a suitable set or
required and/or recommended algorithms.
* MSM: What I'm hearing is that we should think generally and not
just about hashing algorithms but also the criteria by which we
choose. I don't have any suggestions. A systematic decision would
be better than a casual one. I think that means someone needs to
volunteer to do research.
* RD: I wonder if it might make sense to add additional functions:
one that's a default hash that returns the name of a sensible
default hashing algorithm recommended by the implementor. And maybe
an available-algorithms function.
* DN: I heard what RD said, but I think we're deviating far away from
the original proposal. I think we just need one modern algorithm.
+ ... What MSM said is true, it would really be great if someone
could do some research.
* WP: I agree with everything I've heard so far. Managing the list is
a hard problem. I feel a little on the hook because I work with the
sorts of people who could answer the question.
ACTION: QT4CG-079-01: WP to seek expert advice on hashing functions.
* CG: One question regarding the current proposal: this is BLAKE3
without the defaults. What about supporting keyed hashes?
* DN: If we get expert advice, hopefully that question will be
answered.
* NW: I implemented all of the BLAKE3 options to amuse myself one
evening; I
j think it wouldn't be easy with the current function signature.
* JK: I like the idea RD has of a hashes-available function.
* RD: I just checked and Java has an API that supports testing what
algorithms are available.
Proposal: leave this until we hear back from WP.
2.3. PR #1062/#1027/#1227: fn:ranks
* See PR [44]#1227
* See PR [45]#1062
* See PR [46]#1027
* DN: I'm a little reluctant to talk in the absence of MK. I just
wanted to say that I don't think the proposals are in that much
conflict. With two proposals, we should try to synthesize what's
best between them.
+ ... My proposal is a radical simplification, just a single key
function. There was a long discussion and I proved it was
possible.
+ ... I am not insisting on a key function, so we can use the
approach that MK took.
+ ... What I think is missing in MK's proposal is an additional
argument that by default only creates distinct items in every
rank.
+ ... This is a new function, so we could reorder the arguments
so that the collation sequence is not so awkward to use.
* NW: Can you attempt to work with MK to come up with a unified
proposal.
Leave until after XML Prague. DN will attempt to work with MK.
2.4. PR #1108: 566-partial Describe a less aggressive %-encoding for
fn:build-uri
See PR [47]#1108
NW attempts to describe the PR.
* RD: Do we want to specify that the path segment characters are
encoded exclusively or do we want implementors to be allowed to
encode additional ones.
* NW: I think it would be better if we had a single algorithm for all
implementations.
* CG: Did you have time to look at the test cases?
* NW: I did, but I don't have a PR yet.
Proposal: merge this PR.
Accepted.
NW describes his recent rewrite of fn:parse-uri for discussion in the
future.
2.5. PR #1185: 1179 array:values, map:values -> array:get, map:get
See PR [48]#1185
CG: Introduced merge conflicts; looking at [49]the issue instead.
* CG: We could drop the array-values and map-values functions and
just use array:get and map:get.
+ ... We could extend the functions to get more functionality by
making the arguments optional.
Some discussion of how wildcard arguments and the function syntax
intract.
* MSM: I guess it's not quite orthogonality, but more user
expectations, should we consider: would it be better to allow the
functional form to accept an argument of * just for parallelism?
* CG: I think if the * is a string, it'll already give that value.
* RD: I was going to suggest updating the XPath spec, but I see it's
been updated to use the pairs accessor and things so we don't need
to update it to say map?* is equivalent to map:get() although it
may be worth adding that in a note in XPath.
Some discussion of the goal: it's to get a flat sequence.
* DN: Do we have a good way to represent the unflattened members or
values? We're losing information and not considering the question
of getting the data without loss. I think that the operator MK
introduced is sufficient.
* CG: I'm not sure how that's related to this issue. How would you
use the new syntax here?
Some question if there was confusion about the question.
* RD: With the new lookup modifier, the items modifier returns the
flat list. Pairs returns the pairs and values returns a structured
sequence of arrays to preserve the grouping. You can use those.
+ ... If you want specific values, you can specify those in a
parenthesized sequence to the lookup operator.
* CG: Yes.
* DN: Maybe we need more examples?
* RD: There are examples in the postfix lookup section.
* DN: But I mean for these functions. We need to do a better job of
grouping things together. We should have a single section on
records, for example.
* CG: I think the best way is to create a separate issue on that.
+ ... My hope was to make it easier with these two functions.
* NW: I think reducing the number of functions is good.
CG agrees to finalize the PR after the meeting.
2.6. Issue #850: fn:parse-html: Finalization
See issue [50]#850
* RD: MK has opened a PR that needs sorting. I was planning on
removing most of the supported HTML variants and just saying use
HTML 5.
+ ... We can just say HTML 5 or later.
+ ... I'll work on simplifying the API arguments.
RD to perhaps work with MK on the open PR.
3. Any other business
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/05-28.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/05-28.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/05-28.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/05-28.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/05-28.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/05-28.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/05-28.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/05-28.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/05-28.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/05-28.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/05-28.html#blocked
12. https://qt4cg.org/meeting/minutes/2024/05-28.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2024/05-28.html#close-without-action
14. https://qt4cg.org/meeting/minutes/2024/05-28.html#technical-agenda
15. https://qt4cg.org/meeting/minutes/2024/05-28.html#pr-1237
16. https://qt4cg.org/meeting/minutes/2024/05-28.html#pr-1228
17. https://qt4cg.org/meeting/minutes/2024/05-28.html#pr-1062
18. https://qt4cg.org/meeting/minutes/2024/05-28.html#pr-1108
19. https://qt4cg.org/meeting/minutes/2024/05-28.html#pr-1185
20. https://qt4cg.org/meeting/minutes/2024/05-28.html#iss-850
21. https://qt4cg.org/meeting/minutes/2024/05-28.html#any-other-business
22. https://qt4cg.org/meeting/minutes/2024/05-28.html#adjourned
23. https://qt4cg.org/meeting/minutes/
24. https://qt4cg.org/
25. https://qt4cg.org/dashboard
26. https://github.com/qt4cg/qtspecs/issues
27. https://github.com/qt4cg/qtspecs/pulls
28. https://qt4cg.org/meeting/agenda/2024/05-28.html
29. https://qt4cg.org/meeting/minutes/2024/05-21.html
30. https://qt4cg.org/meeting/agenda/2024/06-04.html
31. https://qt4cg.org/dashboard/#pr-1062
32. https://qt4cg.org/dashboard/#pr-956
33. https://qt4cg.org/dashboard/#pr-921
34. https://qt4cg.org/dashboard/#pr-871
35. https://qt4cg.org/dashboard/#pr-832
36. https://qt4cg.org/dashboard/#pr-529
37. https://qt4cg.org/dashboard/#pr-1243
38. https://qt4cg.org/dashboard/#pr-1233
39. https://github.com/qt4cg/qtspecs/issues/1000
40. https://github.com/qt4cg/qtspecs/issues/908
41. https://github.com/qt4cg/qtspecs/issues/894
42. https://qt4cg.org/dashboard/#pr-1237
43. https://qt4cg.org/dashboard/#pr-1228
44. https://qt4cg.org/dashboard/#pr-1227
45. https://qt4cg.org/dashboard/#pr-1062
46. https://qt4cg.org/dashboard/#pr-1027
47. https://qt4cg.org/dashboard/#pr-1108
48. https://qt4cg.org/dashboard/#pr-1185
49. https://github.com/qt4cg/qtspecs/pull/1185#issuecomment-2101774348
50. https://github.com/qt4cg/qtspecs/issues/850
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 28 May 2024 16:22:38 UTC