- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 22 Oct 2024 17:51:44 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m28qugm673.fsf@saxonica.com>
Hello,
Here are the minutes from today:
https://qt4cg.org/meeting/minutes/2024/10-22.html
(Merging one of the PRs has caused a spec build problem in the stylesheets that attempt to generate tests. I don’t think it will effect local builds, and perhaps not even PR builds.)
QT4 CG Meeting 095 Minutes 2024-10-22
[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/8]
* [8]1. Administrivia
+ [9]1.1. Roll call [10/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 [3/8]
+ [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. Close without action
o [19]1.6.4. Substantive PRs
* [20]2. Technical agenda
+ [21]2.1. PR #1513: 1512 Disallow reserved names in namespace
and PI constructors
+ [22]2.2. PR #1511: 1345 Re-allow bare-brace map constructors
everywhere
+ [23]2.3. PR #1504: 868 fn:intersperse -> fn:join,
array:join($arrays, $separator)
+ [24]2.4. PR #1501: 1318 Function Coercion: Records, Maps,
Arrays
* [25]3. Any other business
* [26]4. Adjourned
Draft Minutes
Summary of new and continuing actions [0/8]
* [ ] 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-088-01: NW to consider how best to add a dedication to
MSM.
* [ ] QT4CG-088-04: [Someone] needs to update the processing model
diagram needs vis-a-vis the static typing feature
* [ ] QT4CG-089-01: CG to draft a PR that attempts to resolve the
operators described in #755 to a smaller number of orthogonal
choices.
* [ ] QT4CG-095-01: MK to mark the UnreservedNCName toke as XQuery
only.
* [ ] QT4CG-095-02: MK to add usage advice about computed
constructors
* [ ] QT4CG-095-03: CG to consider what to do about coercion causing
keys to become duplicates in #1501.
1. Administrivia
1.1. Roll call [10/12]
SF gives regrets.
* [X] David J Birnbaum (DB)
* [X] Reece Dunn (RD)
* [ ] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [ ] Ed Porter (EP)
* [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-10-22.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-10-22.png
Figure 2: Open issues by specification
issues-by-type-2024-10-22.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 29 October. Any regrets?
DB gives regrets.
Note: The QT4CG operates on European civil time. In Europe and the
United Kingdom, summer time ends on 27 October. In the United States,
summer time ends on 3 November. That means the meeting of 29 October
will be one hour later in the United States.
1.5. Review of open action items [3/8]
(Items marked [X] are believed to have been closed via email before
this agenda was posted.)
* [ ] 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-088-01: NW to consider how best to add a dedication to
MSM.
* [ ] QT4CG-088-04: [Someone] needs to update the processing model
diagram needs vis-a-vis the static typing feature
* [ ] QT4CG-089-01: CG to draft a PR that attempts to resolve the
operators described in #755 to a smaller number of orthogonal
choices.
* [X] QT4CG-094-01: CG to revise the proposal to serialize as jsonl
+ New PR #1497
* [X] QT4CG-094-02: CG to revise the proposal to have err:stack-trace
return a function item
+ Revised PR #1470
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]#1470: 689 fn:stack-trace: replace with $err:stack-trace
* PR [30]#1505: 1503 Add err:map, err:stack-trace, err:additional to
XSLT
+ Not technically blocked, but should be merged along with #1470
* PR [31]#1454: 1449 Relax rules on multiple xsl:includes
* PR [32]#1296: 982 Rewrite of scan-left and scan-right
* PR [33]#1283: 77b Update expressions
* PR [34]#1062: 150bis revised proposal for fn:ranks
* PR [35]#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 [36]#1518: Add to changes metadata
* PR [37]#1517: 1516(A) Fix failing F&O examples
* PR [38]#1510: 1509 Drop obsolete/redundant text about "import
schema" location hints
* PR [39]#1508: 1507 Make format-integer spec legible
JLO asked to discuss:
* [40]#1502: 1458 Arguments that have a default value but don't
accept ()
JLO asks, what does this do?
* CG: We made a number of parameters optional. Which is what we do
elsewhere.e
+ ... If you omit the value in fn:id(), you get different
semantics.
+ ... So we won't make them optional in that case.
+ ... There are only four exceptions.
* JLO: Thanks. Now I understand.
Proposal: merge these PRs without discussion
Accepted.
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 [41]#1179: Editorial: `array:values`, `map:values`
* Issue [42]#1169: Maps & Arrays: Consistency & Terminology
* Issue [43]#1114: Partial function application: Keywords and
placeholders
* Issue [44]#1065: fn:format-number: further notes
* Issue [45]#735: Local functions in XSLT
* Issue [46]#573: Node construction functions
Proposal: close these issues with no further action.
Accepted.
1.6.4. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [47]#1513: 1512 Disallow reserved names in namespace and PI
constructors
* PR [48]#1511: 1345 Re-allow bare-brace map constructors everywhere
* PR [49]#1504: 868 fn:intersperse -> fn:join, array:join($arrays,
$separator)
* PR [50]#1501: 1318 Function Coercion: Records, Maps, Arrays
* PR [51]#1498: 1366 Use ++ and ** operators in EBNF
* PR [52]#1497: 1471 JSON Serialization: json-lines
* PR [53]#1496: 1495 Drop context value static type
* PR [54]#1454: 1449 Relax rules on multiple xsl:includes
* PR [55]#1227: 150 PR resubmission for fn ranks
2. Technical agenda
2.1. PR #1513: 1512 Disallow reserved names in namespace and PI constructors
See PR [56]#1513
* MK: This just applies the decisions we already made to avoid
ambiguity in element and attribute constructors to namespace and PI
constructors where they also apply.
+ ... Slightly different syntax because they use NCNames not
QNames
+ ... Closely parallel to what we already have for elements and
attributes
* JWL: I checked and this does solve the ambiguity changes.
+ ... But you also added the new NCName
ACTION: QT4CG-095-01: MK to mark the UnreservedNCName toke as XQuery
only.
* DN: What are the reserved names?
* MK: We decided that all of the XPath keywords would be reserved
names.
+ ... This is all in XQuery.
* JLO: I still think that div will be a problem. I'd like to see some
guidance for users.
* MK: This is a computed constructor for a constant name, so you
wonder why this is used.
* RD: It can be useful because the computed constructors make it
easier to include the context in a brace. So you don't wind up with
a mixture of angle brackets and braces.
* MK: I confess, I never construct nodes with XQuery.
* JLO: It's often used if you want to do something like change the
name of a node and copy all its attributes.
* WP: What's the status of automatically rewriting XQuery for
upgrades.
* DN: As WP reminded us, even though we're forbidding some names,
they're perfectly valid. They can actually exist. It seems a bit
restrictive to forbid them completely.
+ ... Is there some other way to encode the names.
* MK: Just write them in quotes.
* JWL: This list is actually larger than the ones that would actually
give you ambiguity. The ambiguity only occurs when it's a binary
operator.
* MK: There are keywords like return that cause a lot of trouble.
* RD: To answer WP's point, it should be possible to detect that
you're running XQuery 4 and on the elements that are direct
NCNames, you can check them. The editor action for the error could
be to add quotes. That shouldn't be too difficult to do in tooling.
* CG: As JLO indicated, I think it would be useful to present the
quoted syntax as the preferred approach. We could add new keywords
in the future.
ACTION: QT4CG-095-02: MK to add usage advice about computed
constructors
Proposal: Accept this PR.
Accepted.
2.2. PR #1511: 1345 Re-allow bare-brace map constructors everywhere
See PR [57]#1511
MK introduces the issue. This is why we did all the reserved names!
* MK: This gets rid of standaloneExpr which we don't need anymore.
+ ... (It incidentally standardizes on calling them "curly
brackets" not curly braces, per Unicode)
+ ... There's quite a bit of text on using expressions that
start and end with curly brackets inside an enclosed
expression. You may need whitespace in some cases.
Proposal: Accept this PR.
Accepted.
2.3. PR #1504: 868 fn:intersperse -> fn:join, array:join($arrays, $separator)
See PR [58]#1504
CG introduces the PR.
* CG: This is an older issue, [59]#868. We have three functions that
do similar things, joining their arguments sometimes with
separators.
+ ... This renames them all to join and allows a separator.
+ ... For consistency, I allowed a sequence for the separator in
string-join.
+ ... The name intersperse was deemed too technical, so we call
it join as well.
* JWL: Are a number of those signatures missing return types?
* CG: I think it's a rendering issue in the diff.
* MK: I have two anxieties, the first is that I really don't see the
value in string-join of allowing the separator to be a sequence.
It's orthogonal, but not really useful. It seems unnecessary to add
that. The other anxiety is the name "join". I think that "join" to
a lot of people means a relational equi-join. In particular, if
there isn't a separator, joining a sequence is a nop. That's not
true of string-join, although it is possible now with concat but it
didn't used to be.
+ ... The name join doesn't seem to capture the flavor of what
that function is for: inserting separators.
* CG: Most languages only allow a single separator, so we could rever
this.
+ ... The main reason why I renamed everything to join because
we have array:join although it's a bit different. Most folks
who have used array:join will probably know what join does. We
could enforce the second parameter. It could be an empty
sequence.
+ ... It was a user of ours that asked why the function is not
called join, because string-join is very widespread in other
languages.
* RD: With the array:join is the separator an optional parameter?
* CG: Yes.
* RD: It defaults to an empty array so the two are kind of mutally
exclusive.
* CG: Yes, but it could also be an empty sequence.
Some discussion of the optionality (or not) of the second parameter to
array:join.
* CG: When the empty array is used, it will give you the same results
as the old join.
* MK: I think I understand RD's point. The only effect of removing
the question would be to disallow supplying an empty sequence
there. It seems more logical to supply an empty array. No need to
provide two ways.
* RD: So queries that supply a separator would error if that resulted
in an empty sequence.
* JLO: I misread the proposal because when I see "join", I think of
"string-join". I wasn't even thinking of database joins. So maybe
it is misleading. The same is true for array:join to me.
* CG: We have lots of use cases for it in the past. For example,
inserting <hr/> between ./para elements.
+ We added a sequence here, but it could be a single separator.
* DN: I think the name string-join is not only very good. It should
be strings-join.
+ ... The other thing is that join is very overloaded. There are
many possible synonyms for join.
* CG: Yes, string-join doesn't make too much sense today because you
can pass arbitrary items. You can pass any atomic type.
+ ... One reason we need to stick to "join" is because
fn:string-join and array:join already exist. But we could add
functions with different names, but I was trying to unify
things.
The term sequence-join gets nods of approval as an alternative to join.
* JLO: Isn't sequence-join just the same as a ,-operator? It would
break my expectation to add separators.
* WP: I agree sequence-join is better than the alternatives. I think
intersperse is interesting, but maybe harder to describe. I don't
think we can change fn:string-join. But renaming join is probably
the best balance.
* DN: I support what WP says. I think the word "build" might be a
better alternative to join.
+ ... Just "join" doesn't have any connotation of a separator.
It would be nice to reduce the number of functions.
CG will revise the PR.
* JLO: For the sake of discoverability and consistency, why don't we
have a two item function that does something for array with a
different name. Maybe the new thing could be for sequences and
arrays.
2.4. PR #1501: 1318 Function Coercion: Records, Maps, Arrays
See PR [60]#1501
* CG: The current coercion rules have become fairly complex. The
coercion rules allow you to convert an input to all kinds of
different outputs. Most recently, rules were added for records.
This allows you to coerce a map to a record.
+ ... I'm not sure it makes sense to put everything in the
coercion rules, but MK convinced me that it is good if it's
all in one place.
+ ... But we don't have coercion rules for arrays.
CG refers to the comments in [61]#1318.
* CG: I added rules for maps and arrays.
CG reviews the new rules.
* MK: I'm slighly concerned about converting the map keys because it
can make the keys duplicate and invalidate the map.
* CG: Yes, I haven't covered that.
* MK: I'm concerned about performance, but I'm aware that isn't very
logical. We have to consider all the members of a sequence, but
this is clearly a similar case.
ACTION: QT4CG-095-03: CG to consider what to do about coercion causing
keys to become duplicates in #1501.
* JWL: Maps are degenerate functions. So in function coercion, you
have to invert the sense on the argument. Is that true of map keys?
* CG: I don't think we need to do that for the keys.
* JWL: It's a question about "subsumed by" going the other way around
on the arguments.
+ ... Am I confusing function signature mapping and coercion?
* MK: I see where you're getting to, but I don't think it applies.
* JLO: I like this a lot. I do not have performance concerns yet. I
have a slightly off-topic question. What's the difference between
xs:int instead of xs:integer.
* CG: You can use xs:integer if you want to restrict the size.
3. Any other business
* NW: It didn't make it onto the agenda, but I'd like to merge #1521,
the editorial change to the ToC in Functions and operators. Any
objection?
None heard, merge the PR.
Some discussion about the fact that it only applies to F&O at the
moment. We'll need to add change markup to the other specifications.
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/10-22.html#minutes
7. https://qt4cg.org/meeting/minutes/2024/10-22.html#new-actions
8. https://qt4cg.org/meeting/minutes/2024/10-22.html#administrivia
9. https://qt4cg.org/meeting/minutes/2024/10-22.html#roll-call
10. https://qt4cg.org/meeting/minutes/2024/10-22.html#agenda
11. https://qt4cg.org/meeting/minutes/2024/10-22.html#so-far
12. https://qt4cg.org/meeting/minutes/2024/10-22.html#approve-minutes
13. https://qt4cg.org/meeting/minutes/2024/10-22.html#next-meeting
14. https://qt4cg.org/meeting/minutes/2024/10-22.html#open-actions
15. https://qt4cg.org/meeting/minutes/2024/10-22.html#open-pull-requests
16. https://qt4cg.org/meeting/minutes/2024/10-22.html#blocked
17. https://qt4cg.org/meeting/minutes/2024/10-22.html#merge-without-discussion
18. https://qt4cg.org/meeting/minutes/2024/10-22.html#close-without-action
19. https://qt4cg.org/meeting/minutes/2024/10-22.html#substantive
20. https://qt4cg.org/meeting/minutes/2024/10-22.html#technical-agenda
21. https://qt4cg.org/meeting/minutes/2024/10-22.html#pr-1513
22. https://qt4cg.org/meeting/minutes/2024/10-22.html#pr-1511
23. https://qt4cg.org/meeting/minutes/2024/10-22.html#pr-1504
24. https://qt4cg.org/meeting/minutes/2024/10-22.html#pr-1501
25. https://qt4cg.org/meeting/minutes/2024/10-22.html#any-other-business
26. https://qt4cg.org/meeting/minutes/2024/10-22.html#adjourned
27. https://qt4cg.org/meeting/agenda/2024/10-22.html
28. https://qt4cg.org/meeting/minutes/2024/10-22.html
29. https://qt4cg.org/dashboard/#pr-1470
30. https://qt4cg.org/dashboard/#pr-1505
31. https://qt4cg.org/dashboard/#pr-1454
32. https://qt4cg.org/dashboard/#pr-1296
33. https://qt4cg.org/dashboard/#pr-1283
34. https://qt4cg.org/dashboard/#pr-1062
35. https://qt4cg.org/dashboard/#pr-529
36. https://qt4cg.org/dashboard/#pr-1518
37. https://qt4cg.org/dashboard/#pr-1517
38. https://qt4cg.org/dashboard/#pr-1510
39. https://qt4cg.org/dashboard/#pr-1508
40. https://qt4cg.org/dashboard/#pr-1502
41. https://github.com/qt4cg/qtspecs/issues/1179
42. https://github.com/qt4cg/qtspecs/issues/1169
43. https://github.com/qt4cg/qtspecs/issues/1114
44. https://github.com/qt4cg/qtspecs/issues/1065
45. https://github.com/qt4cg/qtspecs/issues/735
46. https://github.com/qt4cg/qtspecs/issues/573
47. https://qt4cg.org/dashboard/#pr-1513
48. https://qt4cg.org/dashboard/#pr-1511
49. https://qt4cg.org/dashboard/#pr-1504
50. https://qt4cg.org/dashboard/#pr-1501
51. https://qt4cg.org/dashboard/#pr-1498
52. https://qt4cg.org/dashboard/#pr-1497
53. https://qt4cg.org/dashboard/#pr-1496
54. https://qt4cg.org/dashboard/#pr-1454
55. https://qt4cg.org/dashboard/#pr-1227
56. https://qt4cg.org/dashboard/#pr-1513
57. https://qt4cg.org/dashboard/#pr-1511
58. https://qt4cg.org/dashboard/#pr-1504
59. https://github.com/qt4cg/qtspecs/issues/868
60. https://qt4cg.org/dashboard/#pr-1501
61. https://github.com/qt4cg/qtspecs/issues/1318
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 22 October 2024 16:51:50 UTC