- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 20 Feb 2024 17:49:53 +0000
- To: "public-xslt-40@w3.org" <public-xslt-40@w3.org>
- Message-ID: <m2le7fm3de.fsf@saxonica.com>
Hello,
Here are today’s minutes.
https://qt4cg.org/meeting/minutes/2024/02-20.html
QT4 CG Meeting 066 Minutes 2024-02-20
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/10]
* [3]1. Administrivia
+ [4]1.1. Roll call [8/13]
+ [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 [9/18]
+ [10]1.6. Review of open pull requests and issues
+ [11]1.7. Review of open pull requests and issues
o [12]1.7.1. Merge without discussion
o [13]1.7.2. Close without action
* [14]2. Technical Agenda
+ [15]2.1. PR #1023: 1020 explain consequences of function
coercion
+ [16]2.2. PR #1022: 999 Allow comments in regular expressions
+ [17]2.3. PR #1028: 960(partial) Recognize alternative
representation of JSON null
+ [18]2.4. PR #953: 617 Define record constructors
+ [19]2.5. PR #916: 720 Allow methods in maps with access to
$this
+ [20]2.6. PR #832: 77 Add map:deep-update and array:deep-update
+ [21]2.7. PR #1008: 1002 Add fn:take-while function (replacing
subsequence-before)
+ [22]2.8. PR #1027: 150 fn:ranks
* [23]3. Any other business
* [24]4. Adjourned
[25]Meeting index / [26]QT4CG.org / [27]Dashboard / [28]GH Issues /
[29]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [0/10]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [ ] QT4CG-056-04: MK to write a proposal for adding a select
attribute to xsl:text
* [ ] QT4CG-058-02: MK to consider providing more advice about the
pitfalls of mixing decimal and double when sorting
* [ ] QT4CG-063-01: MK to revise #956 especially with respect to the
options parameter
* [ ] QT4CG-063-02: JK to consider whether the roman numeral example
is appropriate for the spec.
* [ ] QT4CG-063-04: NW to try to add test review to the editorial
meeting.
* [ ] QT4CG-063-05: MK to revise PR #953 to take account of CG's
comments
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [ ] QT4CG-064-08: NW to open an issue to try to resolve $search to
$target consistently.
* [ ] QT4CG-065-01: CG to amend PR #795 to address MK's comment re:
implementation defined behavior
* [ ] QT4CG-066-01: MK to add a note that the grammar rules for
regular expressions apply after comments are removed
1. Administrivia
1.1. Roll call [8/13]
Regrets: JLO, EP
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:07-]
* [X] Michael Kay (MK)
* [ ] Juri Leino (JLO)
* [X] John Lumley (JLY)
* [X] Dimitre Novatchev (DN)
* [ ] Wendell Piez (WP)
* [ ] Ed Porter (EP)
* [ ] Adam Retter (AR) [:10-]
* [ ] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [30]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2024-02-20.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-02-20.png
Figure 2: Open issues by specification
issues-by-type-2024-02-20.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [31]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [32]is scheduled for Tuesday, 27 February 2024.
Any regrets for the next meeting?
1.5. Review of open action items [9/18]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [ ] QT4CG-056-04: MK to write a proposal for adding a select
attribute to xsl:text
* [ ] QT4CG-058-02: MK to consider providing more advice about the
pitfalls of mixing decimal and double when sorting
* [ ] QT4CG-063-01: MK to revise #956 especially with respect to the
options parameter
* [ ] QT4CG-063-02: JK to consider whether the roman numeral example
is appropriate for the spec.
* [ ] QT4CG-063-04: NW to try to add test review to the editorial
meeting.
* [ ] QT4CG-063-05: MK to revise PR #953 to take account of CG's
comments
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [ ] QT4CG-064-08: NW to open an issue to try to resolve $search to
$target consistently.
* [ ] QT4CG-065-01: CG to amend PR #795 to address MK's comment re:
implementation defined behavior
1.6. Review of open pull requests and issues
1.7. Review of open pull requests and issues
1.7.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 [33]#1025: 1001 Fix incorrect operator precedence in
subsequence-where
* PR [34]#795: 655 fn:sort-with
Proposal: merge without discussion.
Approved.
1.7.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 [35]#1005: regular expressions - whitespace
* Issue [36]#709: (Un)Checked Evaluation
* Issue [37]#459: Eager and lazy evaluation
* Issue [38]#356: array:leaves
* Issue [39]#135: Arrays' counterparts for functions on sequences,
and vice versa
* Issue [40]#94: Functions that determine if a given sequence is a
subsequence of another sequence
* Issue [41]#43: Support standard and user-defined composite values
using item type definitions
Proposal: close without action
Accepted.
2. Technical Agenda
2.1. PR #1023: 1020 explain consequences of function coercion
See PR [42]#1023
Mike suggests we should give this one a quick review.
* MK: In 3.8.2 Function Coercion in XQuery...
+ ... It's always been true that you apply the coercion rules
whether you need to or not.
+ ... It turns out that function conversion isn't a no-op in
that case. It's illustrated in a couple of examples in the
spec.
MK walks through the example.
* MK: The coerced function will check that the argument is the right
type, this is a small backwards incompatibility because we
previously didn't check the argument types.
+ ... I think this is a case where the backwards incompatibility
is reasonable, it's doing what the user would expect.
* JLY: This is a consequence of the contravariance.
* MK: Yes.
Proposal: Accept this PR.
Accepted.
2.2. PR #1022: 999 Allow comments in regular expressions
See PR [43]#1022
* MK: I think this is pretty straight-forward. But do we want to do
it in the particular way described?
MK reviews the details: you can escape # because it's used for
comments...and you can use it for comments
* MK: For compatibility reasons, we have to introduce a new flag for
it.
+ ... It's similar to comment syntaxes in other languages but
we're constrained by attribute value normalization.
* MSM: Was using XQuery and XPath comment syntax considered?
* MK: I considered it before doing it this way! It doesn't work
because "):" already means something.
* RD: There's a capturing group that starts with a colon.
* JK: For clarification, applying this with flags means that no
changes need to be made to what a valid regex is.
* MK: I haven't attempted to change the grammar for regular
expressions; we didn't do that when we added whitespace.
ACTION: MK to add a note that the grammar rules for regular expressions
apply after comments are removed
Proposal: merge this PR.
Accepted.
2.3. PR #1028: 960(partial) Recognize alternative representation of JSON null
See PR [44]#1028
* MK: This addresses part of the issue of the lookup operator
flattening sequences. The issue is that when you search a structure
of maps and array using the lookup operator. Normally when you
parse JSON, the leaves are all singletons. The exception is that
the JSON null value gets turned into an empty sequence which means
they get lost.
+ ... That's fine when you're using it for the value of a
property that means the same thing as the property being
absent, then it becomes difficult to do the searching.
* MK: What this proposes is that you can choose a different
representation for null when you parse JSON.
+ ... The "null" option can be set to any value and that value
will be used in the XDM when you hit a JSON null.
+ ... There's an example that shows this using a magic QName
(fn:null) that has the feature that it's recognized by the
serializer (in the JSON output method).
* RD: In the serializer, should we have an option to say what the
null value is?
* MK: The problem is that you have to deal with equality or a node or
a deep map or any number of things. It just gets a bit complicated.
* RD: So should the parse option just allow fn:null then?
* MK: There's some logic there, but you might legitimately want to
use -1 or 0. They won't want it serialized back to null.
* RD: That will also allow compatibility with JSONiq which uses a
special object.
* DN: Is this true for any occurrence of fn:null, not just ones that
came from parse json?
* MK: yes.
* MSM: I like allowing the user to specify any value they want, but I
wonder if a keyword value like fn:null might be a little simpler
than constructing a QName. A keyword would be a little easier to
type than xs:QName('fn:null')
+ ... I wonder if the trade off is worth considering?
* JLY: How often are people going to be doing this? Is going to be
frequent enough to warrant a workaround?
* MK: I think it's a fairly infrequent requirement.
* CG: I'd prefer a binary choice here, not an open user choice.
* JLY: This is the only QName that can occur from parse-json, right?
* MK: Yes.
* JLY: Could the integer parse function produce a QName?
* MK: ... Maybe!
Proposal: Accept this PR?
Accepted.
2.4. PR #953: 617 Define record constructors
See PR [45]#953
MK introduces the PR.
* MK: This interacts with other proposals, but let's look at its
current state and see where we get to.
+ ... It's defined mostly in the constructor functions section
of F&O.
MK reviews the prose in 20.6. It's also mentioned in XQuery and XSLT
where you declare item types.
* MK: I had an action to try to simplify the syntax for declaring
record types.
+ ... There have also been suggestions for adding support for
defaults values.
+ ... Hopefully we can extend this in the feature.
* JK: The constructor functions are built during static analysis.
* MK: Yes, it's equivalent to having the declare function immediately
after the declare type.
* MK: Let's look at the XSLT case where there's also import
precedence to consider.
+ ... We see immediate simplification in the complex number
example.
+ ... In fact, you aren't creating an XSLT function, so import
precedence doesn't come into play.
* JK: We should make sure there are tests that use use-when and other
things that impact the static context.
* RD: The reasons we're using "record test" (instead of "record
type") is because it's defined in sequence item type matching.
* MK: And that's because they're used in node tests in axis
expressions; that's the history.
Some discussion of how attempting to support the name "record type"
might impact the spec. MK has been trying to separate those parts in
the specification.
Some discussion of defaults. Adding them to the record test would be
nice, but there's a risk that users will misunderstand that it's only
for the constructor function.
Proposal: accept this PR
Accepted.
2.5. PR #916: 720 Allow methods in maps with access to $this
See PR [46]#916
This proposal is overtaken by events. It has been closed.
2.6. PR #832: 77 Add map:deep-update and array:deep-update
See PR [47]#832
Not ready for discussion. Need to finish the specification on pinned
and labeled values first.
2.7. PR #1008: 1002 Add fn:take-while function (replacing subsequence-before)
See PR [48]#1008
* MK: This fills in a gap in subsequence functions. It's the common
case of all of the items from the beginning of a sequence up to the
one that satisfies an expression.
+ ... It's a functional way of getting what the while clause
does on FLOWR.
* JLY: Isn't the function required to be a boolean?
* MK: I assume that we're going to adopt the proposal to use EBV for
predicates.
* CG: Shouldn't we have drop-while as well? All the languages I know
of that have take-while also have drop-while
* NW: Is it findability or user expectations?
* RD: Could we have an example of implementing a drop-while? Didn't
we have example somewhere?
* MK: We've dropped the appendix of user-written functions
* NW: I think the parity of functions is important for useability.
* DN: Isn't this sometimes called skip-while?
* CG: Yes, it's sometimes called that.
* RD: Could we at least add an example of how to implement drop-while
in the section on take-while?
* MK: We can certainly do that.
* CG: I added an example in the pull request.
Porposal: Accept this PR.
Accepted.
2.8. PR #1027: 150 fn:ranks
See PR [49]#1027
There isn't time to complete this item today; we'll start with this
issue next week.
DN offers an overview of the ideas in the proposal.
* MK: There's some complexity here with respect to removal of
duplicates. Would it be simpler to keep the duplicates?
* DN: This corresponds to the SQL definition of ranking; this is the
semantic that users would expect.
3. Any other business
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/02-20.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/02-20.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/02-20.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/02-20.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/02-20.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/02-20.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/02-20.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/02-20.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/02-20.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/02-20.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/02-20.html#open-pull-requests
12. https://qt4cg.org/meeting/minutes/2024/02-20.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2024/02-20.html#close-without-action
14. https://qt4cg.org/meeting/minutes/2024/02-20.html#technical-agenda
15. https://qt4cg.org/meeting/minutes/2024/02-20.html#pr-1023
16. https://qt4cg.org/meeting/minutes/2024/02-20.html#pr-1022
17. https://qt4cg.org/meeting/minutes/2024/02-20.html#pr-1028
18. https://qt4cg.org/meeting/minutes/2024/02-20.html#pr-953
19. https://qt4cg.org/meeting/minutes/2024/02-20.html#pr-916
20. https://qt4cg.org/meeting/minutes/2024/02-20.html#pr-832
21. https://qt4cg.org/meeting/minutes/2024/02-20.html#pr-1008
22. https://qt4cg.org/meeting/minutes/2024/02-20.html#pr-1027
23. https://qt4cg.org/meeting/minutes/2024/02-20.html#any-other-business
24. https://qt4cg.org/meeting/minutes/2024/02-20.html#adjourned
25. https://qt4cg.org/meeting/minutes/
26. https://qt4cg.org/
27. https://qt4cg.org/dashboard
28. https://github.com/qt4cg/qtspecs/issues
29. https://github.com/qt4cg/qtspecs/pulls
30. https://qt4cg.org/meeting/agenda/2024/02-20.html
31. https://qt4cg.org/meeting/minutes/2024/02-13.html
32. https://qt4cg.org/meeting/agenda/2024/02-27.html
33. https://qt4cg.org/dashboard/#pr-1025
34. https://qt4cg.org/dashboard/#pr-795
35. https://github.com/qt4cg/qtspecs/issues/1005
36. https://github.com/qt4cg/qtspecs/issues/709
37. https://github.com/qt4cg/qtspecs/issues/459
38. https://github.com/qt4cg/qtspecs/issues/356
39. https://github.com/qt4cg/qtspecs/issues/135
40. https://github.com/qt4cg/qtspecs/issues/94
41. https://github.com/qt4cg/qtspecs/issues/43
42. https://qt4cg.org/dashboard/#pr-1023
43. https://qt4cg.org/dashboard/#pr-1022
44. https://qt4cg.org/dashboard/#pr-1028
45. https://qt4cg.org/dashboard/#pr-953
46. https://qt4cg.org/dashboard/#pr-916
47. https://qt4cg.org/dashboard/#pr-832
48. https://qt4cg.org/dashboard/#pr-1008
49. https://qt4cg.org/dashboard/#pr-1027
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 20 February 2024 17:50:45 UTC