- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 12 Dec 2023 17:41:12 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2r0jr71xy.fsf@saxonica.com>
Hello,
Here are the minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2023/12-12.html
QT4 CG Meeting 058 Minutes 2023-12-12
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/6]
* [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 [4/8]
+ [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. 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 #881: 866 Introduce and exploit new
numeric-compare() function
+ [18]2.2. PR #880: 872 Symmetry: fn:items-at -> fn:get
* [19]3. Any other business?
* [20]4. Adjourned
[21]Agenda index / [22]QT4CG.org / [23]Dashboard / [24]GH Issues /
[25]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
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) [:05-]
* [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 [26]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2023-12-12.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2023-12-12.png
Figure 2: Open issues by specification
issues-by-type-2023-12-12.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [27]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [28]is scheduled for Tuesday, 19 December 2023.
Any regrets for the next meeting?
JL gives regrets.
We will take a holiday recess on 26 December and 2 January, 2024.
1.5. Review of open action items [4/8]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [X] 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.
* [ ] 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
* [X] QT4CG-057-01: CG to make a PR for changing items to subsequence
in some functions.
* [X] QT4CG-057-02: CG to make the list of options in deep-equal
alphabetical again
* [X] QT4CG-057-03: CG to attempt to clarify that the unordered
option in deep-equal only applies to the top-level sequence
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]#863: 742 Drop xsl:function-library declaration
* PR [30]#832: 77 Add map:deep-update and array:deep-update
* PR [31]#795: 655: fn:sort-with
* PR [32]#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 [33]#884: 862 Add explanations and examples of implausible
expressions
* PR [34]#879: 844 New sequence functions: names
* PR [35]#875: XQFO, chap. 9 minor edits
* PR [36]#873: 865 Improve explanation of equality comparisons
* PR [37]#870: 867 Explain defaults in function signatures
* PR [38]#863: 742 Drop xsl:function-library declaration
* PR [39]#849: 847 Allow uri-structure-record keys to have empty
sequence values
* PR [40]#798: 479: fn:deep-equal: Input order
Proposal: merge without discussion.
Approved.
1.6.3. XSLT focused
The following PRs appear to be candidates for a future XSLT-focused
meeting.
* PR [41]#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 [42]#742: xsl:function-library: keep, drop, or refine?
* Issue [43]#168: XSLT Extension Instructions invoking Named
Templates
1.6.4. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [44]#881: 866 Introduce and exploit new numeric-compare()
function
* PR [45]#880: 872 Symmetry: fn:items-at -> fn:get
* PR [46]#874: 878 Proposed extension to subsequence
* PR [47]#737: 295: Boost the capability of recursive record types
1.6.5. Proposed for V4.0
The following issues are labled "proposed for V4.0".
* Issue [48]#850: fn:parse-html: Finalization
* Issue [49]#829: fn:boolean: EBV support for more item types
* Issue [50]#716: Generators in XPath
* Issue [51]#689: fn:stack-trace: keep or drop?
* Issue [52]#583: array:replace(), etc
* Issue [53]#557: fn:unparsed-binary: accessing and manipulating
binary types
* Issue [54]#340: fn:format-number: Specifying decimal format
* Issue [55]#260: array:index-of
* Issue [56]#33: json parsing number type option
* Issue [57]#31: Extend FLWOR expressions to maps
2. Technical Agenda
2.1. PR #881: 866 Introduce and exploit new numeric-compare() function
See PR [58]#881
MK introduces the PR.
* MK: We've done a fair bit to solve the transitivity problems of
things that depend on equals. We made a transitive function for
maps in 3.1; we've changed for-each and grouping to use that
transitive function. But we still have problesm with ordering
comparisons, for sorting especially.
+ ... This proposal handles sorting in XSLT and XQuery and
things like min/max and highest/lowest.
+ ... The function is also exposed publicly for user
convenience.
* MK: The changes are in functions, XSLT, and XQuery.
* MK reviews the fn:numeric-compare function as described in F&O.
* MK: Editorially, the min/max functions have changed a lot but the
technical changes are intended to be small.
+ ... Rather than having pseudo-code, which was problematic,we
simply say in prose what the results must be.
* MK reviews the changes in XQuery Order By
+ ... And similar rules for XSTL
* DN: I think this is a good idea. I have a few questions; it says
doubles are converted to arbitrary position decimals. I think that
"arbitrary" is a little troubling.
* MK: Let's check the detail on that...(MK returns to that part of
the F&O spec)
+ ... The spec doesn't actually say "arbitrary".
Some review of what the actual prose in rule 5.
* DN: This is still problematic.
* MK: But the spec is clear about implementation limits.
* DN: I'm not sure that all xs:double values can be represented in
xs:decimal.
* MK: Yes, that's true.
* DN: We should probably have some examples of groups of doubles that
are the same in decimals.
* DN: It says that NaN is equal to itself and less than everything
else. In that case, is NaN less than negative infinity? It's not
symmetrical to positive infinity.
* MK: I don't see how you can make it symmetrical.
+ ... This defines the results of numeric compare, but some
functions like min and max handle NaN specially. So these
rules don't apply.
* DN: I'd be even happier few could have -NaN and ~+NaN~...
* MK: Yes, but those are in IEEE but we don't support them.
* DN: Isn't sorting when NaN values are involved always unstable?
* MK: That's why, for sorting purposes, we treat NaN as equal to
itself.
* MK: The only thing that's actually changed here is how doubles and
decimals are compared.
* CG: I've already given some feedback in the issue. One of my
concerns is that ordinary users might not want to differentiate
between fn:compare and fn:numeric-compare.
+ ... What I eventually did was create a new issue to generalize
the fn:compare function to take advantage of
fn:numeric-compare.
* MK: I think that a generalized fn:compare has both benefits and
drawbacks.
* CG: Should we make this function private if we have another
function?
* MK: I just don't like the fact that users will use min with two
arguments to get the same results and that's clumsy.
* JK: Does anything need to be said in the rules or examples about -0
and its comparison with +0.
* MK: That's a good point...yes, it should say that negative and
positive zero are equal.
ACTION: MK to clarify in fn:numeric-compare that -0 and +0 are equal.
* DN: I think that comparing double 0.1 to decimal 0.1 returns
greater is quite confusing and users should never mix the types.
That seems like a problem with this function.
* MK: It's a problem with XQuery and XSLT as they exist already.
We're not introducing this problem, we're just trying to solve it.
You are allowed to mix them and it's easy to do accidentally
because xs:untypedAtomic values are xs:double and you might mix
them with xs:decimal
+ ... This doesn't solve all the problems, but it does fix the
problems of transitivity that cause problems in things like
sort.
* DN: Could we add a precision argument? That would eliminate
surprises.
* MK: If you're doing a sort, force everything to decimal. That's a
better solution.
* DN: This should be put in a note somewhere.
* MK: A lot of our users don't understand the subtlties of floating
point arthimetic.
ACTION: MK to consider providing more advice about the pitfalls of
mixing decimal and double when sorting
* MSM: A simple statement of how many decimal places are needed to
distinguish doubles and decimals.
* MK: It's certainly bounded by the size of the mantissa in IEEE.
+ ... And there's also an issue of scale.
Proposal: accept this PR.
Accepted.
2.2. PR #880: 872 Symmetry: fn:items-at -> fn:get
See PR [59]#880
* CG: This is just a proposal to align the function names across data
types.
+ ... There is still the fact that fn:get accepts multiple items
where array:get and map:get don't.
+ ... I've made a separate issue for that but I don't think we
need to make that change.
* DN: I think the name is very general and that can cause confusion.
If we really want this function, I would say something like
"get-from-indexes" or "get-from-positions".
* CG: The basic question is whether we want to align the function
names.
* DN: I think this is a change that will bring complexity and
confusion for regular users.
* MSM: For what it's worth, the one way in which I think renaming the
function as fn:get falls short of making it analagous is precisely
that default namespaces will mean that I write array:get but get
will have a different presentation. The naked get without a
namespace prefix or a hyphen (items-at) does make me think that I
have to look this up. It may be that items-at is a little clearer
in that respect.
* RD: In that case should we have a "sequence" namespace for
sequence-based operations?
* MSM: That would, in fact, address the asymmetry that I think about.
But sequences are so fundamental that I think that would
problematic for other reasons.
CG presents the summary table in issue #843.
* CG: The idea was to make this more consistent, but I can see your
point.
* SF: Would another name do that?
* CG: I think the question is really about whether we want to try to
align the names.
* JK: This is related to the discussion we had last week about the
sprawl of names. This is an example of some fixes we might do, but
what do you think should come next? What's the answer?
* CG: I think this would be one. I've listed many other functions,
but I'm not sure that we can fix all of them.
Some discussion of the problematic semantics of exists and array:exists
and others.
* CG: I think we do have to look at the functions separately. But I
thought that items-at was low hanging fruit.
* DN: I want to thank CG for the tables in this issue. And I think JK
is asking the right questions. We are solving the wrong problem.
We're trying to fix the symptoms not the root cause. This would
involve a lot of work in the future. It's a waste of effort to
discuss all of these names independently. We need something more
general, like a "kollection", that we can use to describe the
abstract type.
* RD: Two points. First, I think it generally makes sense to align
names where it's possible. But if there's confusion then choosing
an alternate, sensible name makes sense. Second, I wonder if it
would make sense to include this table of references in the F&O
specification so that when a user is looking at fn:empty they can
see there are other functions that do similar sorts of things.
* CG: I think it would be nice to have this table, but it's subtle
because the functions aren't all exactly the same.
* RD: This might help someone who, for example, is confused about why
fn:count always returns "1" for an array. It's more an aid to
users.
* MK: Generally, I don't feel that strongly about this either way,
but I want to make one point. The thing I don't like about the name
items-at is the plural. I think 90% of the time it's used to select
a single item. Code should be as readable as possible and the
implication that it's selecting multiple items when it's only
selecting one can lead to misreadings.
Proposal: accept this PR?
DN objects, but consensus is to accept this PR.
* SF: What about similar approaches on different standards? For
example Java decided that the collection APIs should be both
syntactically and semantically similar.
+ ... Do we want to bring those arguments into 4.0.
* MK: We do need to consider what other languages do. We had that
debate last week about the truth values of empty arrays where
Python and JavaScript differ.
* SF: I think it's also about perception from users. And about why
other groups have made those choices.
* MK: Java has objects and can use inheritance, we can't.
* NW: I think we also have to accept that we have some legacy here.
We aren't starting with a green field.
* SF: Operational generic algorithms would allow us to get out of
this problem. But not if we change all of the names.
* DN: I wanted to say that I'm surprised no one else objected given
that in the discussion there were other folks who didn't like the
name.
* MK: I think the challenge here is that we have to make decisions on
individual proposals while considering the broader picture. But
until we have specific proposals about the broader issues, it's
hard to make progress on them.
* DN: I think we should leave this open. I think we need to keep
talking about it. Do not move foward with this PR, withdraw it and
work on the broader proposal.
* JL: We've got the problem that items-at (which is new in 4.0) that
takes a sequence of integers and produces a sequence of outputs.
What we're talking about is moving to a get to align it better with
maps and arrays. What if we had just a single argument, not a
sequence? Then we don't have the items-at problem, you'll only get
one or zero items.
* WP: I think the last point is interesting and should be taken up. I
think DN is making valid points. The resisitence is real, but we
need a process to deal with these sorts of problems. First agree
that we need a better name, then agree on what it does before we
name it.
* MSM: I think I like the proposal that JL and CG endorsed with the
one possible refinement item-get. Kind of roughly sort of parallel
to array:get.
* SF: Do we want to make a completely new API that would allow us to
fix this? Instead of using naming conventions, create a general
namespace-based API that we can use with some generality?
Chair asks for advice about what to do. The advice is to leave this
open for a week.
* NW: Ok. But I'm going to put a hard time-box around it next week
unless the discussion is about fundamentally different ideas.
3. Any other business?
* NW: Do we want to consider changing the time of the meeting? We
know there are folks that aren't participating becuase this slot is
impossible.
Several folks nod affirmatively.
* RD: Could we consider alternating times on different weeks of no
one time works?
* NW: We could, but that's kind a complicated.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2023/12-12.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/12-12.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/12-12.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/12-12.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/12-12.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/12-12.html#so-far
7. https://qt4cg.org/meeting/minutes/2023/12-12.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2023/12-12.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2023/12-12.html#open-actions
10. https://qt4cg.org/meeting/minutes/2023/12-12.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2023/12-12.html#blocked
12. https://qt4cg.org/meeting/minutes/2023/12-12.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2023/12-12.html#xslt-focused
14. https://qt4cg.org/meeting/minutes/2023/12-12.html#substantive
15. https://qt4cg.org/meeting/minutes/2023/12-12.html#proposed-40
16. https://qt4cg.org/meeting/minutes/2023/12-12.html#technical-agenda
17. https://qt4cg.org/meeting/minutes/2023/12-12.html#h-B7E5FAD6-9738-4BB6-A4C9-3F741D6B0DB8
18. https://qt4cg.org/meeting/minutes/2023/12-12.html#h-DC545309-6A5B-4A3C-AE70-132ABC98B442
19. https://qt4cg.org/meeting/minutes/2023/12-12.html#any-other-business
20. https://qt4cg.org/meeting/minutes/2023/12-12.html#adjourned
21. https://qt4cg.org/meeting/minutes/
22. https://qt4cg.org/
23. https://qt4cg.org/dashboard
24. https://github.com/qt4cg/qtspecs/issues
25. https://github.com/qt4cg/qtspecs/pulls
26. https://qt4cg.org/meeting/agenda/2023/12-12.html
27. https://qt4cg.org/meeting/minutes/2023/12-05.html
28. https://qt4cg.org/meeting/agenda/2023/12-19.html
29. https://qt4cg.org/dashboard/#pr-863
30. https://qt4cg.org/dashboard/#pr-832
31. https://qt4cg.org/dashboard/#pr-795
32. https://qt4cg.org/dashboard/#pr-529
33. https://qt4cg.org/dashboard/#pr-884
34. https://qt4cg.org/dashboard/#pr-879
35. https://qt4cg.org/dashboard/#pr-875
36. https://qt4cg.org/dashboard/#pr-873
37. https://qt4cg.org/dashboard/#pr-870
38. https://qt4cg.org/dashboard/#pr-863
39. https://qt4cg.org/dashboard/#pr-849
40. https://qt4cg.org/dashboard/#pr-798
41. https://qt4cg.org/dashboard/#pr-871
42. https://github.com/qt4cg/qtspecs/issues/742
43. https://github.com/qt4cg/qtspecs/issues/168
44. https://qt4cg.org/dashboard/#pr-881
45. https://qt4cg.org/dashboard/#pr-880
46. https://qt4cg.org/dashboard/#pr-874
47. https://qt4cg.org/dashboard/#pr-737
48. https://github.com/qt4cg/qtspecs/issues/850
49. https://github.com/qt4cg/qtspecs/issues/829
50. https://github.com/qt4cg/qtspecs/issues/716
51. https://github.com/qt4cg/qtspecs/issues/689
52. https://github.com/qt4cg/qtspecs/issues/583
53. https://github.com/qt4cg/qtspecs/issues/557
54. https://github.com/qt4cg/qtspecs/issues/340
55. https://github.com/qt4cg/qtspecs/issues/260
56. https://github.com/qt4cg/qtspecs/issues/33
57. https://github.com/qt4cg/qtspecs/issues/31
58. https://qt4cg.org/dashboard/#pr-881
59. https://qt4cg.org/dashboard/#pr-880
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 12 December 2023 17:42:15 UTC