- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 21 May 2024 18:24:30 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m28r03t6wh.fsf@saxonica.com>
Hi folks,
Here are today’s draft minutes:
https://qt4cg.org/meeting/minutes/2024/05-21.html
QT4 CG Meeting 078 Minutes 2024-05-21
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [2/8]
* [3]1. Administrivia
+ [4]1.1. Roll call [8/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. Merge without discussion
o [12]1.6.2. Close without action
* [13]2. XML Prague agenda preparation
* [14]3. Technical Agenda
+ [15]3.1. PR #1117: 1116 Add options param to unparsed-text
+ [16]3.2. PR #1197: 1192 Allow fn as abbreviation for function
+ [17]3.3. PR #1191: 1167, 934 deep equal merge collations param
+ [18]3.4. PR #1185: 1179 array:values, map:values -> contents
+ [19]3.5. PR #1062/#1027/#1227: fn:ranks
+ [20]3.6. PR #1228: Adding the BLAKE3 hashing algorithm to
fn:hash
+ [21]3.7. PR #1219: 1218 Drop use of union(A,B) syntax
+ [22]3.8. PR #1217: 1207 Allow numeric predicates when
filtering arrays
+ [23]3.9. PR #1213: 1199 Add ellipsis markup for arguments in
variadic functions
+ [24]3.10. PR #1212: 1208 correct details of formerly-reserved
function names
+ [25]3.11. PR #1211: QT4CG-076-01 Add examples of coercions
+ [26]3.12. PR #1209: 1183 Add transient mode and the
transient{} expression
* [27]4. Any other business
* [28]5. Adjourned
[29]Meeting index / [30]QT4CG.org / [31]Dashboard / [32]GH Issues /
[33]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [2/8]
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [ ] QT4CG-071-06: NW to clarify the cases that are distinguished by
the leading empty string in path segments
* [ ] 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. Administrivia
1.1. Roll call [8/12]
RD, EP gives regrets. JLY gives regrets for three weeks.
* [ ] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [ ] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [ ] John Lumley (JLY)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP) [:15-]
* [ ] Ed Porter (EP)
* [X] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [34]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2024-05-21.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-05-21.png
Figure 2: Open issues by specification
issues-by-type-2024-05-21.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [35]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [36]is scheduled for Tuesday, 28 May 2024.
MK gives regrets. JLY gives regrets for two more weeks.
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
* [ ] QT4CG-071-06: NW to clarify the cases that are distinguished by
the leading empty string in path segments
* [ ] QT4CG-072-03: NW to clarify the round-tripping of URIs
* [X] QT4CG-073-01: NW to proceed with the records/options proposal
and make a PR.
* [X] QT4CG-077-01: DN to create an issue for adding Blake-3.
* [X] QT4CG-077-02: JK to correct the reference to TR29.
* [ ] 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
1.6. Review of open pull requests and issues
1.6.1. 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]#1223: Minor: fixed URL
* PR [38]#1222: 1214: hash examples
* PR [39]#1220: 73 copy&paste typo in fn:graphemes (combining
diaeresis should be ZWJ)
Proposal: Merge with discussion.
Accepted.
1.6.2. 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 [40]#652: Defining a common function library for XPath, XSLT,
and XQuery applications
* Issue [41]#116: Clarify the fn:transform function() wrt multiple
top-level elements
Proposal: Close without action.
Accepted.
2. XML Prague agenda preparation
* Reminder, who will be there?
+ MK, JLO, RD, ...
* What do we want to accomplish?
+ MK: Classify open issues and make a decision about how radical
we want to be in terms of closing the ones deemed inessential
o Must/Nice/Never!
o What do with "nice to haves"
+ MK: Second, a few issues we aren't going to solve without
talking about them
o Nice to have a feel about whether we think we can solve
those
o Do some whiteboarding...
* Scheduling?
+ We know some folks won't be able to attend, I propose that we
schedule an hour Zoom call at the end of the day for anyone
not present who wants to discuss what we've decided. Perhaps
scheduled at the usual time of 17:00CEST (16:00BST, 15:00GMT,
11:00EDT)?
o If so, do we want to meet from 09:00-18:00 or 10:00-18:00
local time?
* MSM: My gut feeling is that if the network will support it, it
would be probably be more convenient if everyone entered the zoom
call.
* NW: Should we start at 09:00 or 10:00?
Silence.
* NW: Then we'll start at 09:00!
3. Technical Agenda
It would be nice to pick off the low-hanging fruit first in preparation
for the face-to-face. I suggest we take the issues in turn, but begin
by estimating if we believe we can close the issue in 10 minutes. If
not, move on to the next. After we've processed all the "easy" ones, we
can loop back around to what's left.
3.1. PR #1117: 1116 Add options param to unparsed-text
See PR [42]#1117
* MK: We have the choice of specifying an encoding or an options map.
+ ... Some confusion about how that worked in
unparsed-text-lines
+ ... I think that's now sorted out.
* CG: The XQuery code for unparsed-text-lines is wrong
* MK: I think that's now okay.
Proposal: accept this PR.
Accepted.
(We return to this following a question by CG)
* CG: In 3.1, different newline characters are allowed and
automatically normalized
+ ... Shall we change the default to "true" so that we're
backwards compatible?
* MSM:
* MK: Thanks for spotting that.
ACTION: QT4CG-078-01: MK to make the default for normalize-newlines on
unparsed-text.
3.2. PR #1197: 1192 Allow fn as abbreviation for function
See PR [43]#1197.
* MK: We already have fn as an abbreviation in inline functions.
+ ... This just allows it in normal function declarations.
Proposal: accept this PR.
Accepted.
3.3. PR #1191: 1167, 934 deep equal merge collations param
See PR [44]#1191.
* MK: This is doing the same kind of thing with the options parameter
(CG projects for MK)
* MK: Instead of a collation parameter and an options parameter,
they're combined
Proposal: accept this PR.
Accepted.
3.4. PR #1185: 1179 array:values, map:values -> contents
See [45]PR #1185.
Skipped on first triage pass.
3.5. PR #1062/#1027/#1227: fn:ranks
See PR [46]#1227 See PR [47]#1062 See PR [48]#1027
Skipped on first triage pass.
3.6. PR #1228: Adding the BLAKE3 hashing algorithm to fn:hash
See PR [49]#1228
* MK: I have no objection, but that's from a position of ignorance as
to which ones are important enough. It's a judgement call.
* WP: Not an expert on hashing algorithms, but in the context of what
people are doing is how do things get added or removed from this
list.
* NW: You can support any you want, this is about what's in the
standard.
* CG: I have no objection, but what if there are others that could be
added? Why is this one more important?
* JLO: As long as there decent Blake3 implementations, then I think
there's no problem. I was hoping for HMAC, for example.
* DN: Why this one? With this one, we have five. CRC32 and MD5 should
be uncontroversial. SHA1 and SHA256, which are known to have
security exploits. Blake3 is the only one without exploits.
+ ... Finally, I think five is the perfect number. And I think
we should do it.
* CG projects rurban.github.io/smhasher/doc/table.html showing that
there are many faster algorithms.
* DN: There are implementations already in Java, C#, and Rust.
* NW: That's true of many, many algorithms. Adding a dependency
isn'ty free.
* CG: I would like to discuss if further.
We'll continue discussion of this item. Please comment on the issue or
in email.
3.7. PR #1219: 1218 Drop use of union(A,B) syntax
See PR [50]#1219
* MK: It's purely editorial, there are places where it still appears
in examples and it's incorrect.
Proposal: accept this PR.
Accepted.
3.8. PR #1217: 1207 Allow numeric predicates when filtering arrays
See PR [51]#1217
* MK: I resisted this initially, but CG was persuasive.
+ ... My main reservation was what do you want back for [1] on
an array?
+ ... Now that you can have multiple numbers, it makes sense to
return an array.
+ ... The implementation required generalizing the predicate
truth value and referring to it.
+ ... You can also use it on maps which is probably useless, but
logically consistent.
Proposal: accept this PR.
Accepted.
3.9. PR #1213: 1199 Add ellipsis markup for arguments in variadic functions
See PR [52]#1213
* MK: Displays the way the signature of a variadic function is
displays.
Proposal: accept this PR.
Accepted.
3.10. PR #1212: 1208 correct details of formerly-reserved function names
See PR [53]#1212
* MK: This corrects the history and justification. It's purely
editorial.
Proposal: accept this PR.
Accepted.
3.11. PR #1211: QT4CG-076-01 Add examples of coercions
See PR [54]#1211
* MK: This just adds some examples.
* CG: I noticed some issues in union and choice types, but they've
been corrected.
Proposal: accept this PR.
Accepted.
3.12. PR #1209: 1183 Add transient mode and the transient{} expression
See PR [55]#1209
* MK: I've tried to remove all the controversy from the discussion.
+ ... This adds a new expression, transient {} which sets the
static context to transient mode.
+ ... This relaxes the implementation requirements for functions
like current-dateTime, doc, etc. so that they are not required
to be stable.
+ ... No obligation on the implementation to do anything
different, but it is allowed to relax the requirement to
deliver the same results every time.
+ ... There's a recommendation about functions that might
particularly benefit from this treatment.
+ ... This is basically implementation-defined territory.
* DN: I'm wondering who would use this and why if implementations are
not required to return different results every time? If users can't
know what will happen, why should they use it?
* MK: If you take the collection function, an implementation of the
function that access the filestore, the requirement to make the
collection stable is quite expensive.
+ ... People are currently using proprietary extensions to say
they want versions of the function that doesn't incur the
overhead.
+ ... This provides a declarative way to address that common use
case.
+ ... Users might do this if they know their implementations
will use it.
* DN: My concern is that if this not an obligation on implementations
to change their behavior, they won't change it.
* MK: That's a valid concern given that the unordered expression is
very rarely used. Most users want results ordered most of the time.
+ ... You can't force an implementation to return different
results.
+ ... We can't formally model changes in the external
environment.
Some discussion of what it means to observe the external. Some
discussion of whether we should use the word "should".
* NW: I think you underestimate how responsive implementors are to
customers.
* JLO: I think fn:random-number-generator could be added to this
list. That would make it more approachable by just returning a
different value each time it's called.
+ ... I'm also wondering if it's implementation-defined that a
function like current-dateTime must return different values.
It could be really problematic if an implementation returns
the same value.
* MK: It's just hard to predict the outside world, you can't for
example, determine whether or not caching will happen in the
network.
* MSM: I wanted to say on the issue of encouraged-but-not-required-to
versus should, "should" has a defined meaning in conformance. I
think that would be a better choice here. And consistency helps
readers.
* MK: Okay.
* WP: I think I agree with that. It's a question of whether this
should be in the specification or should be implementation
behavior. It looks like a useful thing to have a standard way to
say.
ACTION: QT4CG-078-02: MK to update the prose to use the word "should".
* CG: My concerns are similar to DN's. I have some doubt that
implementors will do sufficiently consistent things. Maybe we could
try to make it a little clearer what changes should be expected.
For time measurements we already have another issue about that.
+ ... One example is file append. That function is identified as
non-deterministic so I wouldn't expect transient{} to change
anything.
* MK: There's no determinism required by the specification for file
append.
Some discussion of when an implementation might "know" that a function
was nondeterministic. (Annotations or other API choices, perhaps.)
* CG: I'm not sure who would find this advantageous.
+ ... What happens when a function is invoked through a function
pointer, etc.
* MK: I've made it part of the static context. That would make it
part of the context when the function is created, not invoked.
We'll continue discussion of this item. Please comment on the PR or in
email.
4. Any other business
* NW: Shall I merge my PR for record descriptions?
Some discussion. General agreement that I should.
* DN: Do we have a final description of the record type and all it's
features?
+ ... I'd like to rewrite a couple of features using record
types, but are they ready?
+ ... And are there any implementations that support records?
* MK: Records are pretty stable in the specification except possibly
for edge cases involving recursive record types.
+ ... There's been a stable implementation Saxon for a while
* MK: On the public 12.x branch, we've stopped adding 4.0 features.
We're doing the work on the 13 branch which isn't publicly
available.
5. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/05-21.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/05-21.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/05-21.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/05-21.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/05-21.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/05-21.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/05-21.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/05-21.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/05-21.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/05-21.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/05-21.html#merge-without-discussion
12. https://qt4cg.org/meeting/minutes/2024/05-21.html#close-without-action
13. https://qt4cg.org/meeting/minutes/2024/05-21.html#h-5AA496D5-CADD-45E4-A8AA-614624F8C215
14. https://qt4cg.org/meeting/minutes/2024/05-21.html#technical-agenda
15. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1117
16. https://qt4cg.org/meeting/minutes/2024/05-21.html#h-FC21A285-E29C-474D-99A8-021A81CAE65F
17. https://qt4cg.org/meeting/minutes/2024/05-21.html#h-08A874BB-C635-4661-AE68-192D905F7D9F
18. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1185
19. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1062
20. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1228
21. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1219
22. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1217
23. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1213
24. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1212
25. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1211
26. https://qt4cg.org/meeting/minutes/2024/05-21.html#pr-1209
27. https://qt4cg.org/meeting/minutes/2024/05-21.html#any-other-business
28. https://qt4cg.org/meeting/minutes/2024/05-21.html#adjourned
29. https://qt4cg.org/meeting/minutes/
30. https://qt4cg.org/
31. https://qt4cg.org/dashboard
32. https://github.com/qt4cg/qtspecs/issues
33. https://github.com/qt4cg/qtspecs/pulls
34. https://qt4cg.org/meeting/agenda/2024/05-21.html
35. https://qt4cg.org/meeting/minutes/2024/05-14.html
36. https://qt4cg.org/meeting/agenda/2024/05-28.html
37. https://qt4cg.org/dashboard/#pr-1223
38. https://qt4cg.org/dashboard/#pr-1222
39. https://qt4cg.org/dashboard/#pr-1220
40. https://github.com/qt4cg/qtspecs/issues/652
41. https://github.com/qt4cg/qtspecs/issues/116
42. https://qt4cg.org/dashboard/#pr-1117
43. https://qt4cg.org/dashboard/#pr-1197
44. https://qt4cg.org/dashboard/#pr-1191
45. https://qt4cg.org/dashboard/#pr-1185
46. https://qt4cg.org/dashboard/#pr-1227
47. https://qt4cg.org/dashboard/#pr-1062
48. https://qt4cg.org/dashboard/#pr-1027
49. https://qt4cg.org/dashboard/#pr-1228
50. https://qt4cg.org/dashboard/#pr-1219
51. https://qt4cg.org/dashboard/#pr-1217
52. https://qt4cg.org/dashboard/#pr-1213
53. https://qt4cg.org/dashboard/#pr-1212
54. https://qt4cg.org/dashboard/#pr-1211
55. https://qt4cg.org/dashboard/#pr-1209
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 21 May 2024 17:24:38 UTC