- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 23 Apr 2024 17:31:00 +0100
- To: "public-xslt-40@w3.org" <public-xslt-40@w3.org>
- Message-ID: <m2mspk2g7j.fsf@saxonica.com>
Hello,
Here are the draft minutes from today’s meeting.
https://qt4cg.org/meeting/minutes/2024/04-23.html
QT4 CG Meeting 074 Minutes 2024-04-16
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/5]
* [3]1. Administrivia
+ [4]1.1. Roll call [11/14]
+ [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 [1/5]
+ [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
o [13]1.6.3. Substantive PRs
o [14]1.6.4. Proposed for V4.0
* [15]2. Technical Agenda
+ [16]2.1. PR #1163: 1159 Add filter expressions for maps and
arrays
+ [17]2.2. PR #1157: 1135 Correction to definition of focus
functions
+ [18]2.3. PR #1148: 1143 Coercion rules: handle choice types
before atomization
+ [19]2.4. PR #1137: 161 Variadic functions
+ [20]2.5. PR #1125: 1094 Enhanced lookup expressions
* [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/5]
* [ ] 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-073-01: NW to proceed with the records/options proposal
and make a PR.
* [ ] QT4CG-074-01: MK to remove default values from variadic
arguments
* [ ] QT4CG-074-02: DN to create an issue about allowing function
arguments to have default values
* [ ] QT4CG-074-03: MK to add variadic functions to the XSLT
specification
1. Administrivia
1.1. Roll call [11/14]
Regrets: JLY.
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [ ] John Lumley (JLY)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [ ] Liam Quin (LQ)
* [ ] Adam Retter (AR)
* [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-04-23.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-04-23.png
Figure 2: Open issues by specification
issues-by-type-2024-04-23.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 [30]is scheduled for Tuesday, 30 April 2024.
JLO gives regrets.
1.5. Review of open action items [1/5]
* [ ] 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-072-04: DN to raise an issue about having a function to
test if a collation URI is supported
* [ ] QT4CG-073-01: NW to proceed with the records/options proposal
and make a PR.
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 [31]#1164: 1155 Consistency of glossaries
Proposal: merge without 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 [32]#235: Add multiple=true() option to fn:parse-json and
fn:json-doc
Proposal: close with no further action.
Accepted.
1.6.3. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [33]#1163: 1159 Add filter expressions for maps and arrays
* PR [34]#1157: 1135 Correction to definition of focus functions
* PR [35]#1148: 1143 Coercion rules: handle choice types before
atomization
* PR [36]#1137: 161 Variadic functions
* PR [37]#1125: 1094 Enhanced lookup expressions
* PR [38]#1117: 1116 Add options param to unparsed-text
* PR [39]#1108: 566-partial Describe a less aggressive %-encoding for
fn:build-uri
* PR [40]#1098: 566-partial Editorial improvements for parse-uri
* PR [41]#1087: 1086 Editorial changes to array:values
* PR [42]#1068: 73 fn:graphemes
* PR [43]#1062: 150bis - revised proposal for fn:ranks
* PR [44]#1027: 150 fn:ranks
1.6.4. Proposed for V4.0
The following issues are labled "proposed for V4.0".
* Issue [45]#1069: fn:ucd
* Issue [46]#982: Add position argument to scan-left and scan-right
* Issue [47]#938: Canonical serialization
* Issue [48]#934: String comparison in deep-equal
* Issue [49]#910: Introduce a Kollection object with functions that
operate on all types of items that can be containers of unlimited
number of "members"
* Issue [50]#908: Function identity: documentation, nondeterminism
* Issue [51]#882: fn:chain or fn:compose
* Issue [52]#850: fn:parse-html: Finalization
* Issue [53]#716: Generators in XPath
* Issue [54]#689: fn:stack-trace: keep, drop, replace with
$err:stack-trace ?
* Issue [55]#657: User-defined functions in main modules without
`local` prefix
* Issue [56]#583: array:replace(), etc
* Issue [57]#557: fn:unparsed-binary: accessing and manipulating
binary types
* Issue [58]#150: fn:ranks: Produce all ranks in applying a function
on the items of a sequence
* Issue [59]#31: Extend FLWOR expressions to maps
2. Technical Agenda
2.1. PR #1163: 1159 Add filter expressions for maps and arrays
See PR [60]#1163
MK reviews the proposal.
* MK: This is driven by the fact that we generalized context node to
context item.
+ ... The filter must be a boolean, it doesn't use the EBV.
+ ... This means it isn't confused with positional selection.
+ ... You can use position() and last()
* RD: I'd prefer it if the ?[ wasn't a single token. It could be
confusing for users and you might want to put whitespace to format
the expression, for example putting then [ on a newline.
* DN: I like this, but I take the opposition position from RD. I
think allowing whitespace or comments between the characters would
increase the possibility of error.
+ ... I'm a little bit concerned that we have too many
"ideograms" in the syntax. The possibility of accidental
errors are increasing.
* SF: I think the use of key and value limits the options for
accessing earlier keys in the scope. It would be nice to allow
additional syntax to allow you to explicitly say the key and value
have a particular name.
* MK: You can do that with the more verbose syntax using map or array
functions. Part of the general culture of the XPath language
includes the notion of overriding scopes (consider .).
* SF: I'm talking about making extending it later on.
* CG: I like the proposal; I'd certainly use it. I know that some
folks will think it's too much syntactic sugar.
* RD: On the DN's point, we already have "?*" that can be separated
by whitespace, so I don't see how that's different form "?[". I
wonder if makes sense to move this into a lookup section. That
would mean you could use this on the "??" operator.
* MK: That's one reason why I didn't do it there. The semantics
become quite complicated doing it there!
+ ... One reason I didn't integrate it into lookup expressions
is that it does't do flattening the way lookup expressions do.
* CG: Another remark that I've already made in the comments is that
in many places we're trying to align arrays and maps, but we're
doing something different here.
* MK: We tried to make arrays and maps as consistent as we can, given
that they're different.
* RD: Wouldn't this allow with the for/member discussions? That's a
kind of symmetry.
* MK: One way you could do it is to try treat an array as being a map
with integer keys. But when you look at what people would have to
write it's far less convenient.
* RD: Or if you flattened the map into singleton maps, that makes
access difficult.
Some discussion of how the feature differs from sequences; it's about
the fact that arrays can have items that don't have single items in
them.
Straw poll: "?[" as a single token or two tokens?
Single token: 4 Two tokens: 2
I think single tokens wins.
Proposal: accept the PR.
Accepted.
2.2. PR #1157: 1135 Correction to definition of focus functions
See PR [61]#1157
* MK: This is relatively minor.
+ ... This fixes the bug with narrative prose.
Proposal: accept the PR.
Accepted.
2.3. PR #1148: 1143 Coercion rules: handle choice types before atomization
See PR [62]#1148
Not ready for review. Something has gone wrong in the editing.
2.4. PR #1137: 161 Variadic functions
See PR [63]#1137
* MK: This proposal takes a mininalist approach. It generalizes what
the concat function does and applies them to other functions. A lot
of the discussion in the issue was about more comprehensive
options. This just fixes the fact that concat stands out like a
sore thumb.
+ ... Having said all that, there's an issue with concat in
backwards compatibility mode that I couldn't sort out in a
fully general way!
* MK: It changes concat to be one of these variadic functions, but
most of the technical changes are in the expressions.
* MK: I've reorganized the static context section a bit.
+ ... Function declarations can now be declared to be variadic
MK reviews the description in 4.3 Variadic functions
* DN: Not directly related, but I understand that function items
can't be variadic. But in our current specification, do we allow
arguments of function items to have default values?
* MK: No. I think that's fairly orthogonal. We could potentially do
that.
* MSM: I'm confused by MK's answer to that question. I seem to
remember a proposal that provided for that.
* MK: That's only on static function calls, not dynamic ones.
* RD: Did you talk about default values? I see that concat uses it.
Some discussion of what happens when you call a variadic function that
has a default that isn't the empty sequence.
* MK: If the default wasn't an empty sequence, there'd be some
confusion there. If the occurrence is *, we could insist that it be
the empty sequence.
* DN: I was going to say that it seems logical not to allow defaults
for variadic arguments. That would eliminate the problem.
* RD:
ACTION: QT4CG-074-01: MK to remove default values from variadic
arguments
ACTION: QT4CG-074-02: DN to create an issue about allowing function
arguments to have default values
ACTION: QT4CG-074-03: MK to add variadic functions to the XSLT
specification
2.5. PR #1125: 1094 Enhanced lookup expressions
See PR [64]#1125
* MK: This PR is attempting to address the problem of flattening.
+ ... It extends the syntax of lookup expressions to add a
modifier before the key specifier. It specifies pairs, keys,
values, or items. Items gives the current behavior and that's
the default.
+ ... This PR also adds the type qualifier. It solves the
previous issue related to ambiguity around "?" by putting the
sequence type in parenthesis.
+ ... The type qualifier returns only items that match the
specified type.
MK reviews examples from the specification.
* MK: This is very symmetric between arrays and maps.
* RD: With the type specifier syntax, do we want to align the keyword
with the item type declaration?
* MK: It's a sequence type not an item type.
Some discussion of item type versus sequence type.
* DN: It seems that using pairs or keys for arrays is not very
useful. Also, for maps, using pairs is the natural approach. Maybe
the list of modifiers can be shortened?
* MK: You could call it values for arrays and pairs for maps.
* DN: Pairs on an array gives a very artificial view of an array.
* MK: In many ways, it's driven by orthogonality: apply all the
features for all the data types.
* CG: I think orthogonality is a good thing here. Once we align the
function sets with maps and arrays, we may get even more synergy.
* RD: The values and keys accessors are available in other languages.
* DN: I heard what was said about orthogonality. Maybe I agree.
Probably it would be more precise to say members rather than pairs.
We already talk about members in other places.
* MK: Yes. We don't have "members" for maps, we have "entries".
There's a question about whether we could introduce better
terminology.
* DN: I wouldn't object to renaming "entries" to "members" for maps.
* MK: Or just "entries".
* DN: For arrays, I'm not so sure.
* MK: It would effect a lot of function naming.
* JK: I support values as it stands. It's a nice complement to pairs
and keys. I think many programmers will find that familiar. I also
like pairs because it's not tied to either maps or arrays.
* SF: Usually "members" is associated with object-oriented
programming, so I think other names are more suitable.
* DN: I don't think members are confusing in this case.
Proposal: accept this PR
Accepted.
3. Any other business
Who's planning to be in Prague? MK, JLO, EP, SF, NW.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/04-23.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/04-23.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/04-23.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/04-23.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/04-23.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/04-23.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/04-23.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/04-23.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/04-23.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/04-23.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/04-23.html#merge-without-discussion
12. https://qt4cg.org/meeting/minutes/2024/04-23.html#close-without-action
13. https://qt4cg.org/meeting/minutes/2024/04-23.html#substantive
14. https://qt4cg.org/meeting/minutes/2024/04-23.html#proposed-40
15. https://qt4cg.org/meeting/minutes/2024/04-23.html#technical-agenda
16. https://qt4cg.org/meeting/minutes/2024/04-23.html#pr-1163
17. https://qt4cg.org/meeting/minutes/2024/04-23.html#pr-1157
18. https://qt4cg.org/meeting/minutes/2024/04-23.html#pr-1148
19. https://qt4cg.org/meeting/minutes/2024/04-23.html#pr-1137
20. https://qt4cg.org/meeting/minutes/2024/04-23.html#pr-1125
21. https://qt4cg.org/meeting/minutes/2024/04-23.html#any-other-business
22. https://qt4cg.org/meeting/minutes/2024/04-23.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/04-23.html
29. https://qt4cg.org/meeting/minutes/2024/04-16.html
30. https://qt4cg.org/meeting/agenda/2024/04-30.html
31. https://qt4cg.org/dashboard/#pr-1164
32. https://github.com/qt4cg/qtspecs/issues/235
33. https://qt4cg.org/dashboard/#pr-1163
34. https://qt4cg.org/dashboard/#pr-1157
35. https://qt4cg.org/dashboard/#pr-1148
36. https://qt4cg.org/dashboard/#pr-1137
37. https://qt4cg.org/dashboard/#pr-1125
38. https://qt4cg.org/dashboard/#pr-1117
39. https://qt4cg.org/dashboard/#pr-1108
40. https://qt4cg.org/dashboard/#pr-1098
41. https://qt4cg.org/dashboard/#pr-1087
42. https://qt4cg.org/dashboard/#pr-1068
43. https://qt4cg.org/dashboard/#pr-1062
44. https://qt4cg.org/dashboard/#pr-1027
45. https://github.com/qt4cg/qtspecs/issues/1069
46. https://github.com/qt4cg/qtspecs/issues/982
47. https://github.com/qt4cg/qtspecs/issues/938
48. https://github.com/qt4cg/qtspecs/issues/934
49. https://github.com/qt4cg/qtspecs/issues/910
50. https://github.com/qt4cg/qtspecs/issues/908
51. https://github.com/qt4cg/qtspecs/issues/882
52. https://github.com/qt4cg/qtspecs/issues/850
53. https://github.com/qt4cg/qtspecs/issues/716
54. https://github.com/qt4cg/qtspecs/issues/689
55. https://github.com/qt4cg/qtspecs/issues/657
56. https://github.com/qt4cg/qtspecs/issues/583
57. https://github.com/qt4cg/qtspecs/issues/557
58. https://github.com/qt4cg/qtspecs/issues/150
59. https://github.com/qt4cg/qtspecs/issues/31
60. https://qt4cg.org/dashboard/#pr-1163
61. https://qt4cg.org/dashboard/#pr-1157
62. https://qt4cg.org/dashboard/#pr-1148
63. https://qt4cg.org/dashboard/#pr-1137
64. https://qt4cg.org/dashboard/#pr-1125
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 23 April 2024 16:31:52 UTC