QT4CG Draft Minutes 058, 12 December 2023

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