- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 14 Nov 2023 18:00:09 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2sf58kyd8.fsf@saxonica.com>
Good evening,
Here are the draft minutes from meeting 054:
https://qt4cg.org/meeting/minutes/2023/11-14.html
QT4 CG Meeting 054 Minutes 2023-11-14
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/3]
* [3]1. Administrivia
+ [4]1.1. Roll call [11/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 [5/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
o [13]1.6.3. XSLT focused
o [14]1.6.4. Substantive PRs
o [15]1.6.5. Proposed for V4.0
* [16]2. Technical Agenda
+ [17]2.1. PR #795: 655: fn:sort-with
+ [18]2.2. PR #736: 730: Clarify (and correct) rules for maps as
instances of function types
+ [19]2.3. PR #828: 516 Add position argument to HOF callbacks
+ [20]2.4. Issue #716: Generators in XPath
* [21]3. Any other business?
* [22]4. Adjourned
[23]Agenda index / [24]QT4CG.org / [25]Dashboard / [26]GH Issues /
[27]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [0/3]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [ ] QT4CG-052-05: MK to rename the hexBinary-equal function to
binary-equal?
* [ ] QT4CG-052-06: MK to consider the editorial question of
"promotion" for the symmetric relations.
1. Administrivia
1.1. Roll call [11/11]
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [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-2023-11-14.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2023-11-14.png
Figure 2: Open issues by specification
issues-by-type-2023-11-14.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, 21 November 2023.
JK gives regrets. WP gives possible regrets. MK is traveling but
expects to be here.
1.5. Review of open action items [5/8]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [X] QT4CG-052-01: MP to create a proposal for a
csv-row-record-creation function
* [X] QT4CG-052-02: MP to open an issue about supporting comment
lines.
* [X] QT4CG-052-03: MP to make the changes agreed to #719.
* [X] QT4CG-052-04: MP to open an issue about consistency in the
names of record types
* [ ] QT4CG-052-05: MK to rename the hexBinary-equal function to
binary-equal?
* [ ] QT4CG-052-06: MK to consider the editorial question of
"promotion" for the symmetric relations.
* [X] QT4CG-052-07: NW to move fn:invisible-xml to the section on
parsing and serialization functions
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]#824: 799 errors in examples; 738 section heading for fn:op
* PR [32]#823: 712 Extend array:sort to align with fn:sort
* PR [33]#794: 216: fn:unparsed-text: End-of-line characters
* PR [34]#761: 554/754 Simplify the new transitive-closure function
* PR [35]#719: 413: Spec for CSV-related functions
Proposal: accept 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 [36]#747: QName literals
* Issue [37]#743: Extend enumeration types to allow values other than
strings
Proposal: close without action.
Accepted.
1.6.3. XSLT focused
The following PRs appear to be candidates for a future XSLT-focussed
meeting.
* PR [38]#470: 369: add fixed-prefixes attribute in XSLT
* PR [39]#412: 409, QT4CG-027-01: xsl: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 [40]#742: xsl:function-library: keep, drop, or refine?
* Issue [41]#169: Handling of duplicate keys in xsl:map
* Issue [42]#168: XSLT Extension Instructions invoking Named
Templates
1.6.4. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [43]#828: 516 Add position argument to HOF callbacks
* PR [44]#798: 479: fn:deep-equal: Input order
* PR [45]#795: 655: fn:sort-with
* PR [46]#737: 295: Boost the capability of recursive record types
* PR [47]#736: 730: Clarify (and correct) rules for maps as instances
of function types
* PR [48]#529: 528: revision of json(), and renaming to
elements-to-maps()
1.6.5. Proposed for V4.0
The following issues are labled "proposed for V4.0".
* Issue [49]#716: Generators in XPath
* Issue [50]#689: fn:stack-trace: keep or drop?
* Issue [51]#583: array:replace(), etc
* Issue [52]#340: fn:format-number: Specifying decimal format
* Issue [53]#260: array:index-of
* Issue [54]#91: name of map:substitute
* Issue [55]#33: json parsing number type option
* Issue [56]#31: Extend FLWOR expressions to maps
2. Technical Agenda
2.1. PR #795: 655: fn:sort-with
See PR [57]#795.
CG explains.
* CG: We discussed having a sort function that provides an operator
because the existing function is fairly limited.
+ ... MK has recently extended the functionality of the built-in
sort function.
+ ... So the question is: is this worth persuing.
* JL: I've certainly had to write my own a few times because I needed
comparitor functions, but they were fairly esoteric.
* MK: It's the sort of function that you need very rarely and by few
people, but desperately needed when needed.
* MSM: I'm happier if someone who knows what they're doing has done
it, rather than making me write it!
* JL: Was this considered long ago?
* MK: Yes. At the time, there was a body of opinion that thought our
language should be "safe" and that you shouldn't be able to cause
havoc by providing a badly behaved comparitor function.
+ ... That was the major reason that wasn't provided before.
* NW waffles a bit about slightly in favor versus not doing more
work.
* DN: I wanted to ask if we could just have a standard function with
a default.
* MK: Doesn't the default do exactly what the fn:sort function does?
* DN: Maybe. I haven't thought about it in detail.
* RD: Do we want an order option, like we added to sort?
* MK: You just invert your comparitor function.
* CG: I thought about that, but it's complicated.
* JL: Is there an argument for triple-valued comparitor?
* MK: I'd argue for a three-valued comparitor partly because it's
common.
Some discussion of three-valued comparitor function and stable sorting.
* CG: I think I'll work on finalizing it.
Some discussion of test cases. Basically, all of the conditions in the
text, plus a few edge cases. A couple of dozen for an "ordinary"
function.
* CG: Is the name fn:sort-with ok?
Some grumbling but no suggestions of a better name.
2.2. PR #736: 730: Clarify (and correct) rules for maps as instances of
function types
See PR [58]#736.
MK reviews the PR.
* MK: What is the function signature of a map when treating it as a
function?
+ ... I dodged that question. The data model says that every
function has a signature, but in fact, maps as functions have
to be regarded as having multiple signatures.
+ ... Instead of saying that, I've switched the question around
to ask when a particular map is a valid instance of a
particular function type.
+ ... That's in 3.6.4...
+ ... This fixes a bug that was plainly wrong in the 3.1
specification.
+ ... Then there's a similar section for arrays.
+ ... Plus a few items in the subtyping rules.
* RD: The array section hasn't changed, it's just been expanded and
clarified.
* MK: Yes.
* DN: I understand that the question mark is meaningless, but isn't
it meaningful to have union of empty sequence and type.
* MK: Yes, but I decided this was simpler.
+ ... Expressing it in terms of what is the function signature
of a map immediately leads to problems. For exmaple, what's
the function signature of an empty map. This style of
exposition seems to avoid thos problems.
* RD: A union wouldn't work because unions are only on atomic types
not sequence types.
* MK: That could be done, but it's not in the specification
currently.
Proposal: merge this PR.
Accepted.
2.3. PR #828: 516 Add position argument to HOF callbacks
See PR [59]#828.
CG reviews the PR.
* MK: I did a fairly solid review of the first draft and submitted a
bunch of comments.
+ ... I think CG has fixed those issues but I haven't reviewed
the current draft.
* CG: I tried to scale the PR back to what it was originall.
+ ... We have lots of HoF that take the "remaining items" as a
parameter.
+ ... In JavaScript and other languages, there's an optional
parameter that can count the position in the sequence.
* CG reviews the examples.
* CG: You can't use a positional variable in some and every to solve
all of the use cases.
* CG: I've added it to fn:filter, fn:fold-left and fn:fold-right,
fn:for-each, fn:for-each-pair, fn:index-where, fn:items-before and
fn:items-after, and so on.
* NW: I've certainly used that functionality in JavaScript at least
once or twice.
* JL: Is the positional argument an optional one in all cases?
* CG: Yes. It's part of the function coercion rules that not all
arguments need to be specified.
* DN: How is the parameter meaningful in fold-left or fold-right?
+ ... I'd like to see an example of those cases.
Some discussion of the examples of folding left and right.
* CG: Whenever you have an implementation that chooses different ways
to evaluate the code, you can use a more mathematical approach if
you don't have to specify the position.
* DN: A position doesn't always make sense in right folds which can
be infinite.
* CG: The way we specify sequences, there's always a length.
Proposal: merge this PR.
Accepted.
2.4. Issue #716: Generators in XPath
See issue [60]#716.
NW displays the issue.
* RD: I think we should stick with snake-cased based names, rather
than adding camel-case names.
* DN: I think snake-case comes from Python and it uses underscores.
We switch to sharing DN's screen.
* DN explains.
+ DN: A generator is an iterator that only returns the current
item.
+ ... The two main use cases are when we have a huge collection
but we aren't sure we need all of them.
+ ... Also, if we don't know if the collection is even finite,
then a generator lets us walk through them.
+ ... One good example of such a problem is to generate the
first "N" members of a collection that have some property. For
example, to find the first million prime numbers, we don't
know how many natural numbers we need to scan.
+ ... The proposal is simple. It uses record types.
+ ... DN explains the proposal as defined in the issue.
* NW: What's the spec change?
* DN: We could say why should we use record, it's just a map. We're
using it mostly for convenience, this would also be a convenience.
It would be convenient to have generator and generator-test in the
spec.
* RD: Ideally, generators are a way of writing open-ended sequences.
For example the random number generator in the spec. Currently, you
can't pass that to any filter functions or standard functions
because of the way it's operated.
+ ... But if we had a way of saying that random-number is a
generator function, we could convert that into an XPath
sequence so you could select the first 10 items or do
transforms or what-have-you in standard XQuery.
+ ... On the proposal itself, I'm not convinced that we need the
initialized property; ideally you want the function that
creates the generator object to put it in an initialized
state. That makes it easier for implementors to map the record
properties to Java or C# iterator methods.
* DN: Yes, we could have a kind of generator that just produces the
next random number. As for the comment about not needing
initialized, I can say that I based this on the IEnumerator type in
.NET and they have this feature. There are use cases where it's
useful to have a generator in an un-initialized state. If
initialization is expensive, you might want to delay it until it's
known to be necessary.
(Some discussion about the explicit case of IEnumerator.)
* MK: How does this integrate with current functions that operate on
sequences, FLOWR expressions, etc.
+ ... In Java and C#, you also get "an iterable" and you can use
it in a for expression.
+ ... I don't see that connection in this proposal.
* DN: Good question. Typically in such languages, generators are
implemented as methods or functions that contain something like
yield or yield return, this requires the compiler to rewrite the
whole function as a class.
+ ... I'm not suggesting such a thing here. This is a "poor
man's generator".
+ ... We could have more functions that produce from a given
collection a generator. Things like generator-from-sequence
etc.
* RD: My proposal specifies an fn:sequence function that takes a
generator and returns a sequence back.
+ ... I'm thinking it's best that specific implementation
details are implementation defined.
* MK: That makes sense to me.
* JL: How much of this can we do without actually adding a generator
type into the type system?
+ ... How much could you do with simply a known record type?
* DN: We already have a precedent for using the key/value record
type.
* MK: I think we're starting to use record types often enough that we
could have system-defined ones that are available to everyone in
the language.
* RD: Between the two proposals, a generator is just a record type.
+ ... Effectively a geneator is a custom way of enumerating
through a sequence that is of undefined bounds.
Some discussion of wether or not DN and RD have made equivalent
proposals or not.
3. Any other business?
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2023/11-14.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/11-14.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/11-14.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/11-14.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/11-14.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/11-14.html#so-far
7. https://qt4cg.org/meeting/minutes/2023/11-14.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2023/11-14.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2023/11-14.html#open-actions
10. https://qt4cg.org/meeting/minutes/2023/11-14.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2023/11-14.html#merge-without-discussion
12. https://qt4cg.org/meeting/minutes/2023/11-14.html#close-without-action
13. https://qt4cg.org/meeting/minutes/2023/11-14.html#xslt-focused
14. https://qt4cg.org/meeting/minutes/2023/11-14.html#substantive
15. https://qt4cg.org/meeting/minutes/2023/11-14.html#proposed-40
16. https://qt4cg.org/meeting/minutes/2023/11-14.html#technical-agenda
17. https://qt4cg.org/meeting/minutes/2023/11-14.html#pr-795
18. https://qt4cg.org/meeting/minutes/2023/11-14.html#pr-736
19. https://qt4cg.org/meeting/minutes/2023/11-14.html#pr-828
20. https://qt4cg.org/meeting/minutes/2023/11-14.html#iss-716
21. https://qt4cg.org/meeting/minutes/2023/11-14.html#any-other-business
22. https://qt4cg.org/meeting/minutes/2023/11-14.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/2023/11-14.html
29. https://qt4cg.org/meeting/minutes/2023/11-07.html
30. https://qt4cg.org/meeting/agenda/2023/11-21.html
31. https://qt4cg.org/dashboard/#pr-824
32. https://qt4cg.org/dashboard/#pr-823
33. https://qt4cg.org/dashboard/#pr-794
34. https://qt4cg.org/dashboard/#pr-761
35. https://qt4cg.org/dashboard/#pr-719
36. https://github.com/qt4cg/qtspecs/issues/747
37. https://github.com/qt4cg/qtspecs/issues/743
38. https://qt4cg.org/dashboard/#pr-470
39. https://qt4cg.org/dashboard/#pr-412
40. https://github.com/qt4cg/qtspecs/issues/742
41. https://github.com/qt4cg/qtspecs/issues/169
42. https://github.com/qt4cg/qtspecs/issues/168
43. https://qt4cg.org/dashboard/#pr-828
44. https://qt4cg.org/dashboard/#pr-798
45. https://qt4cg.org/dashboard/#pr-795
46. https://qt4cg.org/dashboard/#pr-737
47. https://qt4cg.org/dashboard/#pr-736
48. https://qt4cg.org/dashboard/#pr-529
49. https://github.com/qt4cg/qtspecs/issues/716
50. https://github.com/qt4cg/qtspecs/issues/689
51. https://github.com/qt4cg/qtspecs/issues/583
52. https://github.com/qt4cg/qtspecs/issues/340
53. https://github.com/qt4cg/qtspecs/issues/260
54. https://github.com/qt4cg/qtspecs/issues/91
55. https://github.com/qt4cg/qtspecs/issues/33
56. https://github.com/qt4cg/qtspecs/issues/31
57. https://qt4cg.org/dashboard/#pr-795
58. https://qt4cg.org/dashboard/#pr-736
59. https://qt4cg.org/dashboard/#pr-828
60. https://github.com/qt4cg/qtspecs/issues/716
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 14 November 2023 18:01:51 UTC