- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 09 Jan 2024 18:36:20 +0000
- To: "public-xslt-40@w3.org" <public-xslt-40@w3.org>
- Message-ID: <m24jfmpd3w.fsf@saxonica.com>
Hi folks,
Here are the draft minutes from today’s meeting.
https://qt4cg.org/meeting/minutes/2024/01-09.html
I’ve merged all the PRs except for one editorial PR that wound up having
merge conflicts. (I’ll merge that as soon as it’s fixed.)
QT4 CG Meeting 060 Minutes 2024-01-09
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/6]
* [3]1. Administrivia
+ [4]1.1. Roll call [10/11]
+ [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 [0/6]
+ [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
o [14]1.6.4. XSLT focused
o [15]1.6.5. Substantive PRs
o [16]1.6.6. Proposed for V4.0
* [17]2. Technical Agenda
+ [18]2.1. PR #874: 878 Proposed extension to subsequence
+ [19]2.2. PR #737: 295: Boost the capability of recursive
record types
+ [20]2.3. PR #909: 893 fn:compare: Support for arbitrary atomic
types
* [21]3. Any other business?
+ [22]3.1. What about PR #880?
+ [23]3.2. Meeting time?
* [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/6]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [ ] QT4CG-052-06: MK to consider the editorial question of
"promotion" for the symmetric relations.
* [ ] QT4CG-055-01: MK to clarify that the return type of the deep
lookup operator is a flat sequence.
* [ ] QT4CG-056-04: MK to write a proposal for adding a select
attribute to xsl:text
* [ ] QT4CG-058-01: MK to clarify in fn:numeric-compare that -0 and
+0 are equal.
* [ ] QT4CG-058-02: MK to consider providing more advice about the
pitfalls of mixing decimal and double when sorting
* [ ] QT4CG-060-01: NW to describe why we're closing #899 without
change
* [ ] QT4CG-060-02: MK to sketch out a proposal with subsequence and
subsequence-where.
* [ ] QT4CG-060-03: MK to review PR and if there are no concerns,
merge it without discussion next weeks
* [ ] QT4CG-060-04: CG to make a PR to remove numeric-compare and
consider other functions
1. Administrivia
1.1. Roll call [10/11]
Regrets: MSM.
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:10-]
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP) [:10-]
* [X] Ed Porter (EP)
* [ ] 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-01-09.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-01-09.png
Figure 2: Open issues by specification
issues-by-type-2024-01-09.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, 16 January 2024.
Any regrets for the next meeting?
1.5. Review of open action items [0/6]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [ ] QT4CG-052-06: MK to consider the editorial question of
"promotion" for the symmetric relations.
* [ ] QT4CG-055-01: MK to clarify that the return type of the deep
lookup operator is a flat sequence.
* [ ] QT4CG-056-04: MK to write a proposal for adding a select
attribute to xsl:text
* [ ] QT4CG-058-01: MK to clarify in fn:numeric-compare that -0 and
+0 are equal.
* [ ] QT4CG-058-02: MK to consider providing more advice about the
pitfalls of mixing decimal and double when sorting
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 [33]#795: 655: fn:sort-with
* PR [34]#529: 528: revision of json(), and renaming to
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 [35]#926: 860 Editorial rearrangement of spec for shallow lookup
* PR [36]#925: 780 Document incompatibility in format-number etc
* PR [37]#924: 648 Disallow user modifications to schema for FN
namespace
* PR [38]#923: 913-new-examples-for-local-name-etc
* PR [39]#922: 915 function body terminology
* PR [40]#918: Minor cx through chap. 14
* PR [41]#914: XQFO minor edits
* PR [42]#912: XQFO: Minor edits
* PR [43]#907: 906 fn:deep-equal: unordered -> ordered
* PR [44]#905: 898 - relax the constraints on document-uri
* PR [45]#904: 821 Annotations: Make default namespace explicit
* PR [46]#901: 895 Parameters with default values: allow empty
sequences
Proposal: merged 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 [47]#899: Simplifying the language - types have behaviour.
Propocal: close without action
* MK: We know this is a problem, but no one's come up with a better
solution. It's an area where adding any additional features will
just make it more complicated.
Accepted.
ACTION QT4CG-060-01: NW to describe why we're closing #899 without
change
1.6.4. XSLT focused
The following PRs appear to be candidates for a future XSLT-focused
meeting.
* PR [48]#871: Action qt4 cg 027 01 next match
These issues identify the XSLT-focused changes that have been made to
the specifications but which have not been established by the community
group as the status quo.
* Issue [49]#168: XSLT Extension Instructions invoking Named
Templates
1.6.5. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [50]#927: 861 Rewrite spec of deep lookup operator
* PR [51]#921: 920 Allow xsl:break and xsl:next-iteration within
branch of xsl:switch
* PR [52]#916: 720 Allow methods in maps with access to $this
* PR [53]#909: 893 fn:compare: Support for arbitrary atomic types
* PR [54]#880: 872 Symmetry: fn:items-at -> fn:get
* PR [55]#874: 878 Proposed extension to subsequence
* PR [56]#832: 77 Add map:deep-update and array:deep-update
* PR [57]#737: 295: Boost the capability of recursive record types
1.6.6. Proposed for V4.0
The following issues are labled "proposed for V4.0".
* Issue [58]#910: Introduce a Kollection object with functions that
operate on all types of items that can be containers of unlimited
number of "members"
* Issue [59]#908: Function identity: documentation still too vague
* Issue [60]#850: fn:parse-html: Finalization
* Issue [61]#829: fn:boolean: EBV support for more item types
* Issue [62]#716: Generators in XPath
* Issue [63]#689: fn:stack-trace: keep or drop?
* Issue [64]#583: array:replace(), etc
* Issue [65]#557: fn:unparsed-binary: accessing and manipulating
binary types
* Issue [66]#340: fn:format-number: Specifying decimal format
* Issue [67]#283: Enumeration types
* Issue [68]#260: array:index-of
* Issue [69]#236: map:group-by or map:build with a sequence of keys
* Issue [70]#33: json parsing number type option
* Issue [71]#31: Extend FLWOR expressions to maps
2. Technical Agenda
2.1. PR #874: 878 Proposed extension to subsequence
See PR [72]#874
* MK: This arises from CG's proposal to rename items-before and
items-after.
+ ... It goes back to an idea of combining them all into a
single function with optional parameters.
* MK: All this PR does is introduce the new function, it would need
more editorial work if accepted.
* MK Describes the changes in the fn:subsequence function.
* RD: In the binding of $temp you've mentioned greater-than-or-equal
but it's le.
* MK: This gives the correct, backwards-compatible answer in the NaN
case.
* DN: It seems very powerful, and I admire powerful things. At the
same time, I'd like to see something less complicated. It's very
easy to get confused. We have two different pairs of
mutually-exclusive arguments. I think this is the first function
with mutually-exclusive arguments.
* MK: The closest analogy is probably fn:slice, which we haven't
looked at all that much.
+ ... We had four separate functions, we had difficulty finding
names for them, but the proliferation is an issue. This swings
the pendulum the other way.
+ ... It gives more functionality than we had before, by using
$from and $length for example.
* DN: I'd like to make a parallel with .NET linq where they're kept
separate. That's much more understandable.
* MK: I like that kind of API, though it's quite hard to optimize
statically. It's hard to see how to introduce that into our
language without mutable iterators and streams.
* DN: We already have generators and collections on the table. It's
just an example of an alternative that's simpler.
* CG: First, i was a bit hesitant about having all the functions in
fn:subsequence, but we implemented it and showed it to users and it
was intuitive.
* RD: It's only $start and $from that are mutally exclusive.
* MK: No, $length$, $while, and $until are exclusive as well.
* RD: Oh, then my idea for using a union doesn't help. We already
have FLOWR based sytnax for working with loops so maybe it makes
sense to look if anything is required there.
* MK: That's an alternative, to add clauses to FLOWR expressions. We
could certainly look at that. I like doing things with functions
rather than syntax, but that would certainly be an option.
* RD: We could have both. There are equivalent expressions that are
supported in the language. We introduced every() and any()
functions as equivalent to the quantifier expressions.
* CG: I wonder if there are many use cases. Do folks really want to
do this?
* MK: I see lots of questions about this on StackOverflow.
* DN: Looking a bit more, it seems to me that it can be two
functions: the existing function and a new function
subsequence-where that has $from and ~\(while\). I think that would
be more useful and understandable.
* NW: That does address a concern I have about making the
subsequence() function more complicated.
* MK: I can sketch that out.
ACTION QT4CG-060-02: MK to sketch out a proposal with subsequence and
subsequence-where.
2.2. PR #737: 295: Boost the capability of recursive record types
* PR [73]#737
* MK reviews the background for the issue.
* MK: John Snelson first proposed an idea like this in a blog post
and pointed me to the relevant literature. These are iso-recursive
types.
* MK: That's about it really, there are no special operators. There's
nothing that enables you to create infinite instances.
* DN: This is another example of something I really like. I have one
question. There are some conditions to prevent infinite/circular
reference. Is there an guarantee that infinite/circular reference
involving multiple types can happen, or do we need explicitly to
specify such conditions? I would like to see a separate chapter
about records in the final spec.
* MK: There are two questions. Can you create an infinite data
structure? No. That's a question of what operators we provide. You
can only create them with the map constructor and such. We don't
have pointers. Do the rules ensure that it is always possible to
construct an instance? It doesn't really matter if you allow users
to construct types that have no instances. That's already true in a
few places. They aren't useful, but they don't do any harm. The
rules, like it has to be an optional field, are a bit paternal. It
means the system will reject some useless types.
* DN: To refine the question: is it possible to have two record
types, each of which references the other type?
* MK: Yes.
* DN: Then we should have an example or prose telling us if creating
such a chain of references is infinite.
* RD: I have three questions. One is, should we remove the
self-reference in the record declarations we have?
* MK: Yes, this is supposed to replace that.
* RD: Two, in the bit where iso-recursive is described, we should
refer to the expanded QName because if we're just doing a simple
name match.
* MK: Yes, I may have just overlooked that because I thought it was
obvious.
* MK: One thing that occurred to me is that we're starting to treat
named record types as being a bit more than just names for things.
+ ... They're no longer just aliases, they're introducing a new
capability.
+ ... One thing I wanted to bounce of people was whether we can
get rid of named item types in general and only having named
record types.
* RD: I think named item types are useful for things like a binary
type locally.
* MK: Unions and enumerations are another example.
* RD: Do we list the named item types as a possibility in the atomic
types and should we?
* MK: I think we do.
Some discussion of what it would mean for named item types to be only
allowed as record types.
* JL: I could see a case where you want to use a named item type as
shortcut for something you didn't want to have to write over and
over.
* JL: Are these all global?
* MK: In XSLT, I don't think we've fully developed it. But I think
they should be subject to the package level visibility. They're not
local. In XQuery they might be module level.
* RD: Should the named item type be with the functions and variables
that have public/private scope in XQuery then?
MK attempts to check what we've actually done.
* MK: Item type declarations do have annotations so they can be
declared public or private. I'm not sure if that's fully developed.
* DN: Is it possible to declare a record type with no fixed fields?
If it's possible then every map is a record that has zero keys. I
think that would be good.
* MK: You can define record(*) which is everything at all.
* DN: Then we can stop talking about maps and only talk about records
with no fields.
Proposal: merge this PR?
ACTION QT4CG-060-03: MK to review PR and if there are no concerns,
merge it without discussion next week
2.3. PR #909: 893 fn:compare: Support for arbitrary atomic types
* PR [74]#909
CG discusses the background of the proposal.
* CG: This is a simpler proposal. It generalizes the compare function
to take any atomic type.
+ ... For all types, the rules are defined using the existing
rules for comparisons.
+ ... The most significant differences are in strings and URIs.
* DN: Don't we already have a op:keys-equal function (not exposed),
isn't that the same? If it isn't, then we should describe how
they're different.
* CG: Are you thinking of atomic-equal?
* DN: No, in XPath 3.0 there's something like op:keys-equal
* MK: Maps are compared with atomic-equal which only cares about
equality. This has a lot of similarities to atomic-equal but it
handles context sensitivity and comparisons (for sorting, for
example).
+ ... We have lots of comparison functions, but they all have a
rationale for existence.
+ ... I support bundling the functionality like this into a
single function.
* MK: Does this make numeric-compare redundant?
* RD: I was going to make the same comment.
* DN: If these are so closely related, will this allow us to
eliminate the other comparison functions?
* MK: We could consider getting rid of the op: versions and putting
it all here, but it doesn't effect users. It would be interesting
to see how that looks.
* CG: I'd like to drop numeric-compare and include it in this
function.
* NW: I like that.
* JK: I support this proposal too.
Proposal: accept this PR
Accepted.
ACTION QT4CG-060-04: CG to make a PR to remove numeric-compare and
consider other functions
3. Any other business?
3.1. What about PR #880?
* NW: What should we do about scheduling continuing discussion of PR
#880?
* MK: It's all tied up with what we do about subsequence.
* NW: Ok, I'll just let it float along in the agenda for a bit.
3.2. Meeting time?
* JL: What's going on with moving the time?
* NW: I haven't had enough replies yet. The replies I have received
don't seem likely to move us. I'll try to nudge folks.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/01-09.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/01-09.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/01-09.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/01-09.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/01-09.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/01-09.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/01-09.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/01-09.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/01-09.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/01-09.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/01-09.html#blocked
12. https://qt4cg.org/meeting/minutes/2024/01-09.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2024/01-09.html#close-without-action
14. https://qt4cg.org/meeting/minutes/2024/01-09.html#xslt-focused
15. https://qt4cg.org/meeting/minutes/2024/01-09.html#substantive
16. https://qt4cg.org/meeting/minutes/2024/01-09.html#proposed-40
17. https://qt4cg.org/meeting/minutes/2024/01-09.html#technical-agenda
18. https://qt4cg.org/meeting/minutes/2024/01-09.html#pr-874
19. https://qt4cg.org/meeting/minutes/2024/01-09.html#pr-737
20. https://qt4cg.org/meeting/minutes/2024/01-09.html#pr-909
21. https://qt4cg.org/meeting/minutes/2024/01-09.html#any-other-business
22. https://qt4cg.org/meeting/minutes/2024/01-09.html#discuss-880
23. https://qt4cg.org/meeting/minutes/2024/01-09.html#meeting-time
24. https://qt4cg.org/meeting/minutes/2024/01-09.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/01-09.html
31. https://qt4cg.org/meeting/minutes/2023/12-19.html
32. https://qt4cg.org/meeting/agenda/2024/01-16.html
33. https://qt4cg.org/dashboard/#pr-795
34. https://qt4cg.org/dashboard/#pr-529
35. https://qt4cg.org/dashboard/#pr-926
36. https://qt4cg.org/dashboard/#pr-925
37. https://qt4cg.org/dashboard/#pr-924
38. https://qt4cg.org/dashboard/#pr-923
39. https://qt4cg.org/dashboard/#pr-922
40. https://qt4cg.org/dashboard/#pr-918
41. https://qt4cg.org/dashboard/#pr-914
42. https://qt4cg.org/dashboard/#pr-912
43. https://qt4cg.org/dashboard/#pr-907
44. https://qt4cg.org/dashboard/#pr-905
45. https://qt4cg.org/dashboard/#pr-904
46. https://qt4cg.org/dashboard/#pr-901
47. https://github.com/qt4cg/qtspecs/issues/899
48. https://qt4cg.org/dashboard/#pr-871
49. https://github.com/qt4cg/qtspecs/issues/168
50. https://qt4cg.org/dashboard/#pr-927
51. https://qt4cg.org/dashboard/#pr-921
52. https://qt4cg.org/dashboard/#pr-916
53. https://qt4cg.org/dashboard/#pr-909
54. https://qt4cg.org/dashboard/#pr-880
55. https://qt4cg.org/dashboard/#pr-874
56. https://qt4cg.org/dashboard/#pr-832
57. https://qt4cg.org/dashboard/#pr-737
58. https://github.com/qt4cg/qtspecs/issues/910
59. https://github.com/qt4cg/qtspecs/issues/908
60. https://github.com/qt4cg/qtspecs/issues/850
61. https://github.com/qt4cg/qtspecs/issues/829
62. https://github.com/qt4cg/qtspecs/issues/716
63. https://github.com/qt4cg/qtspecs/issues/689
64. https://github.com/qt4cg/qtspecs/issues/583
65. https://github.com/qt4cg/qtspecs/issues/557
66. https://github.com/qt4cg/qtspecs/issues/340
67. https://github.com/qt4cg/qtspecs/issues/283
68. https://github.com/qt4cg/qtspecs/issues/260
69. https://github.com/qt4cg/qtspecs/issues/236
70. https://github.com/qt4cg/qtspecs/issues/33
71. https://github.com/qt4cg/qtspecs/issues/31
72. https://qt4cg.org/dashboard/#pr-874
73. https://qt4cg.org/dashboard/#pr-737
74. https://qt4cg.org/dashboard/#pr-909
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 9 January 2024 18:37:44 UTC