QT4CG Draft Minutes 057, 5 December 2023

Hi folks,

Here are the minutes from today’s meeting:

    https://qt4cg.org/meeting/minutes/2023/12-05.html

QT4 CG Meeting 057 Minutes 2023-12-05

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [0/8]
     * [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/9]
          + [10]1.6. Review of open pull requests and issues
               o [11]1.6.1. Merge without discussion
               o [12]1.6.2. Substantive PRs
               o [13]1.6.3. Proposed for V4.0
     * [14]2. Technical Agenda
          + [15]2.1. PR #855: 844 New sequence functions: names
          + [16]2.2. PR #849: 847 Allow uri-structure-record keys to have
            empty sequence values
          + [17]2.3. PR #832: 77 Add map:deep-update and array:deep-update
          + [18]2.4. PR #798: 479: fn:deep-equal: Input order
          + [19]2.5. Issue #829: fn:boolean: EBV support for more item
            types
     * [20]3. Any other business?
     * [21]4. Adjourned

   [22]Agenda index / [23]QT4CG.org / [24]Dashboard / [25]GH Issues /
   [26]GH Pull Requests

Draft Minutes

Summary of new and continuing actions [0/8]

     * [ ] 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.
     * [ ] 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-057-01: CG to make a PR for changing items to subsequence
       in some functions.
     * [ ] QT4CG-057-02: CG to make the list of options in deep-equal
       alphabetical again
     * [ ] QT4CG-057-03: CG to attempt to clarify that the unordered
       option in deep-equal only applies to the top-level sequence

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) [:10-]
     * [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 [27]the agenda.

   Accepted.

1.2.1. Status so far...

   issues-open-2023-12-05.png

   Figure 1: "Burn down" chart on open issues

   issues-by-spec-2023-12-05.png

   Figure 2: Open issues by specification

   issues-by-type-2023-12-05.png

   Figure 3: Open issues by type

1.3. Approve minutes of the previous meeting

   Proposal: Accept [28]the minutes of the previous meeting.

   Accepted.

1.4. Next meeting

   The next meeting [29]is scheduled for Tuesday, 12 December 2023.

   Any regrets for the next meeting?

   None heard.

1.5. Review of open action items [4/9]

     * [ ] 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.
     * [ ] QT4CG-055-01: MK to clarify that the return type of the deep
       lookup operator is a flat sequence.
     * [X] QT4CG-055-02: DN to open an issue requesting examples of
       implausible expressions to clarify the spec
     * [X] QT4CG-056-01: MK to update PR #479 so that it merges cleanly.
     * [X] QT4CG-056-02: MK to update PR #412 so that it merges cleanly.
     * [X] QT4CG-056-03: MK to draft a PR to remove the
       function-namespaces feature.
     * [ ] QT4CG-056-04: MK to write a proposal for adding a select
       attribute to xsl:text

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 [30]#863: 742 Drop xsl:function-library declaration
     * PR [31]#851: 822: XQuery, XQFO: Edits (pool)

   Proposal: accept without discussion?

   Accepted.

1.6.2. Substantive PRs

   The following substantive PRs were open when this agenda was prepared.
     * PR [32]#855: 844 New sequence functions: names
     * PR [33]#849: 847 Allow uri-structure-record keys to have empty
       sequence values
     * PR [34]#832: 77 Add map:deep-update and array:deep-update
     * PR [35]#798: 479: fn:deep-equal: Input order
     * PR [36]#795: 655: fn:sort-with
     * PR [37]#737: 295: Boost the capability of recursive record types
     * PR [38]#529: 528: revision of json(), and renaming to
       elements-to-maps()

1.6.3. Proposed for V4.0

   The following issues are labled "proposed for V4.0".
     * Issue [39]#850: fn:parse-html: Finalization
     * Issue [40]#829: fn:boolean: EBV support for more item types
     * Issue [41]#716: Generators in XPath
     * Issue [42]#689: fn:stack-trace: keep or drop?
     * Issue [43]#583: array:replace(), etc
     * Issue [44]#557: fn:unparsed-binary: accessing and manipulating
       binary types
     * Issue [45]#340: fn:format-number: Specifying decimal format
     * Issue [46]#260: array:index-of
     * Issue [47]#33: json parsing number type option
     * Issue [48]#31: Extend FLWOR expressions to maps

2. Technical Agenda

2.1. PR #855: 844 New sequence functions: names

   See PR [49]#855.

   CG walks us through the issue and the PR.
     * CG: ...with-sequence becomes ...-with-subsequence
     * CG: Discussion of items-after, items-before, items-starting-where,
       and items-ending-where
          + ... Using "subsequence" here would make the names even longer
          + ... One suggestion was a single function that has more
            arguments
          + ... Other languages have imperative sounding functions
            "take-while" and "drop-while"...
          + ... "Items" functions might be more expected for folks from
            the functional background
          + ... Some functions use verbs in the names.
          + ... Trying to avoid very long names.
     * DN: I think this is a useful issue, but it just scratches the
       surface.
          + ... It's telling us about the symptom, not the cause of the
            problem.
          + ... When we have to talk about items, members, pairs, etc. And
            sometimes we need to have functions in the fn, array, and map
            namespaces.
          + ... I think MK made a useful suggestion about having more
            general types of objects.
          + ... I think if we have one general, abstract type of
            collection then we could have all of these functions in
            different namespaces replaced by a single function.
     * CG: I think that's a good observation; in #843, I've listed all of
       the function duplication we already have. And we have new functions
       that we have to discuss if we need multiple equivalent versions of
       them.
     * JL: What's the argument for leaving off the inclusion version; is
       it just the name, or is it that there's no use case.
     * CG: Those are two points: one solution is that we could take the
       two functions that allow you to drop the first or last value.
          + ... Or in many cases you can do it with just a couple of
            existing functions.
          + ... Some of the functions will be more common than others; you
            can always find arguments for all four, but are people really
            going to be aware of them all?
          + ... Many of these use cases can be written with other existing
            functions.
     * JL: Then in the notes, I think it would be good to show some of
       these use cases in the examples.
     * RD: There are really two challenges in creating common sequence,
       array, and map functions. One is that an array or map is a single
       item sequence. So doing a count on that object will return 1,
       whereas array:size and map:size will return the number of elements.
          + ... We can't change that behavior.
          + ... The other challenge is that the different functions have
            slightly different semantics. If you try to get a an item in
            an index of an array that doesn't exist, it'll throw an
            exception. But sequences just return an empty sequence. So
            you've got those semantic differences.
     * CG: Yes, it would definitely be easier if we could start over!
     * MK: I agree with everything RD said. Procedurally, do we focus on
       the big issues per DN, or do we take a small step as CG is
       proposing.
          + ... In terms of the detail of the PR, I sympathise with goals.
            But if we're going to cut down from four to two, we've picked
            the wrong two!
          + ... We also have index-where that you can use to construct
            what you want.
          + ... One could argue that the family of four functions is
            excessive. But I'd keep subsequence-before and
            subsequence-starting-where.
     * CG: What about subsequence-where?
     * MK: I think it makes simple cases more difficult.
     * JK: Subsequence-where doesn't imply that they're contiguous.
     * CG: Yes, that's true.
     * MK: One could do it all by adding keywoard arguments to the
       existing subsequence function.
     * CG: We could have subsequence-from and subsequence-before
     * DN: I want to second what MK said. I think we're making things more
       complex. That's not good for users. In order to cure the symptoms,
       we're making things more complicated.
     * CG: The root cause is a really complex problem.
     * DN: We should work on the root cause. I don't think we've made the
       necessary effort yet.
     * NW: Can we do it the other way around? Make complete parity across
       the namespaces?
     * MK: It doesn't work. There are semantic differences between arrays,
       maps, and sequences.
     * NW: :-(
     * SF: I hear the arguments that we can't do it because of major
       incompatibilities.
          + ... But we could solve this problem by having functions in a
            new namespace.
          + ... If you want a particular semantics, you could point to at
            a specific namespace. That would eliminate the constraints on
            changing logic and versions.
     * NW: More namespaces is better! It's an interesting approach.
     * RD: With this proposal, we've changed items to subsequence. That's
       uncontroversial and we should do it. The other change, combining
       the functions is more controversial. We could separate the two.
          + ... Maybe we could investigate further and continue the
            analysis that CG has done.
     * CG: I think we can drop subsequence-where.
          + Rename items to subsequence
          + How to rename the existing four functions and maybe deal with
            take-while and drop-while
     * MSM: For the record, I hate replacing a two syllable word with a
       three syllable one but I don't see a better alternative.

   ACTION: CG to make a PR for changing items to subsequence in some
   functions.

2.2. PR #849: 847 Allow uri-structure-record keys to have empty sequence
values

   See PR [50]#849.

   NW introduces the question: what's the goup's opinion, should we allow
   empty sequences in the uri-structure-record?
     * MK: I'm in favor of making the fields optional.
     * RD: +1
     * NW: Okay, I'll get this one tidied up for next week.

2.3. PR #832: 77 Add map:deep-update and array:deep-update

   See PR [51]#832.

   Not ready for discussion.

2.4. PR #798: 479: fn:deep-equal: Input order

   See PR [52]#798.

   CG walks us through the PR.
     * CG: The idea is simple, in XQuery 3.1 there were no options on
       fn:deep-equal. In 4.0, we have a lot of options.
          + ... I propose a more general option ordered or unordered that
            simply allows you to enforce order or to allow permutations.
          + ... If you include this option, then you can use all the other
            options as well.
     * MK: Did you say it was easy to implement?
     * CG: Yes!
     * MK: Congratulations!

   Some discussion of how performance is impacted by an implementation.
     * MK: An implementation with quadratic performance isn't difficult!
     * MK: I have a slight concern that we're bundling too much into one
       function, but in principle it makes sense.
     * DN: Maybe I don't understand. If unordered=true means that any
       sequence can be unordered (even element children), I think it's
       very confusing. If a schema says the children can be any order, but
       another element says they have a particular order, would be gross
       violation of the schema.
     * CG shows an example with lists of atomic values.
     * DN: I think it makes sense for atomic values.
     * MK: My reading is that it only applies at the top level.
     * DN: Then that needs to be made very clear! It needs to be
       emphasized.

   Some discussion of how to improve the prose.
     * MK: Perhaps it could be clarified in the description in the table.
     * JL: I understand the mechanism for elements and their children. Is
       there any requirement for unordered comparisons further down?
     * NW: Sometimes you just have to write your own function!
     * RD: I was wondering if it could be useful in the element case for a
       test assertion of some sort, but if this is only at the top
       level... If you had unordered elements specified but unordered set
       to false, then that would work equivalently if the unordered
       elements were the same at the top level.
     * MK: No, this is always the children.

   Some further discussion of this use case.
     * JL: Is there any argument for a wildcard on unordered elements?
     * CG: Not sure. It has been discussed.

   Proposal: Accept this PR?

   Acccepted.

   ACTION: CG to make the list of options in deep-equal alphabetical again

   ACTION: CG to attempt to clarify that the unordered option in
   deep-equal only applies to the top-level sequence

2.5. Issue #829: fn:boolean: EBV support for more item types

   Issue [53]#829.
     * CG: We have EBV for a number of conditionals. It comes form XPath
       1.0 and has the semantics from there.
          + ... I think it would be useful to apply this to more types.
            Today you get an error for maps and arrays. We could also
            consider the binary types.
          + ... We could just return true if an item exists, or we could
            look into it. So an empty array could be either true or false.
          + ... Then you wouldn't have to write array:size() != 0
     * MK: I think the big problem is that doing it the obvious way (empty
       maps and arrays are true) is different from Javascript.
     * JK: But it's the same as Python
     * CG: Are there languages where it's an error?

   Java, for example, and other strongly typed languages.
     * DN: We have more than one way to do this already? Don't we have
       exists and empty in the array and map namespaces?
          + ... I don't see the needs for this. We already have ways to do
            this.
     * CG: My experience is based on some user feedback. Users unfamiliar
       with XPath 1.0 just don't understand why it's sometimes an error.
     * JK: Am I right in thinking that EBV is mostly frequently supported
       in predicate filters in XPath expresions?
     * MK: Yes, that's probably right.
     * JK: So what does array(*) mean in that case?

   Some discussion of the use case. Something like [$a] where $a is an
   array.
     * RD: Here's an example:

let $a := array {}
return if ($a) then 1 else 2

     * CG: It would be nice if it didn't give an exception.
     * MK: Most advice is to be explicit.
     * CG: But it's very convenient that so much of XPath is concise!
     * DN: I am not saying I support this, but looking at the table for
       computing booleans, it's very complicated.
          + ... It should be made easier. Getting the size of a big array
            just to see if it exists is very inefficient.
     * MK: But that's an easy optimization.
     * CG: If you have EBV for sequences, you need the same check.

   Who is in favor of extending EBV to cover more types.

   In favor 4, opposed 3.5.
     * NW: There's no consensus yet. We'll just leave that issue for now.

3. Any other business?

     * DN: I did my action item.
     * NW: Thank you, DN.

4. Adjourned

References

   1. https://qt4cg.org/meeting/minutes/2023/12-05.html#minutes
   2. https://qt4cg.org/meeting/minutes/2023/12-05.html#new-actions
   3. https://qt4cg.org/meeting/minutes/2023/12-05.html#administrivia
   4. https://qt4cg.org/meeting/minutes/2023/12-05.html#roll-call
   5. https://qt4cg.org/meeting/minutes/2023/12-05.html#agenda
   6. https://qt4cg.org/meeting/minutes/2023/12-05.html#so-far
   7. https://qt4cg.org/meeting/minutes/2023/12-05.html#approve-minutes
   8. https://qt4cg.org/meeting/minutes/2023/12-05.html#next-meeting
   9. https://qt4cg.org/meeting/minutes/2023/12-05.html#open-actions
  10. https://qt4cg.org/meeting/minutes/2023/12-05.html#open-pull-requests
  11. https://qt4cg.org/meeting/minutes/2023/12-05.html#merge-without-discussion
  12. https://qt4cg.org/meeting/minutes/2023/12-05.html#substantive
  13. https://qt4cg.org/meeting/minutes/2023/12-05.html#proposed-40
  14. https://qt4cg.org/meeting/minutes/2023/12-05.html#technical-agenda
  15. https://qt4cg.org/meeting/minutes/2023/12-05.html#h-E01573AE-CAC0-43ED-94F6-05094B3AB8A1
  16. https://qt4cg.org/meeting/minutes/2023/12-05.html#h-FF4B88D7-D575-41AE-A6EE-8AB73B7FB618
  17. https://qt4cg.org/meeting/minutes/2023/12-05.html#h-1A7F9ACF-9EC6-4C8E-A13F-FDFD6545C2B5
  18. https://qt4cg.org/meeting/minutes/2023/12-05.html#h-5CBFFA21-18EA-4136-BBF6-06E60CF0ADF5
  19. https://qt4cg.org/meeting/minutes/2023/12-05.html#h-81B61E64-8200-4AC1-AACB-7FC685775CAF
  20. https://qt4cg.org/meeting/minutes/2023/12-05.html#any-other-business
  21. https://qt4cg.org/meeting/minutes/2023/12-05.html#adjourned
  22. https://qt4cg.org/meeting/minutes/
  23. https://qt4cg.org/
  24. https://qt4cg.org/dashboard
  25. https://github.com/qt4cg/qtspecs/issues
  26. https://github.com/qt4cg/qtspecs/pulls
  27. https://qt4cg.org/meeting/agenda/2023/12-05.html
  28. https://qt4cg.org/meeting/minutes/2023/11-28.html
  29. https://qt4cg.org/meeting/agenda/2023/12-12.html
  30. https://qt4cg.org/dashboard/#pr-863
  31. https://qt4cg.org/dashboard/#pr-851
  32. https://qt4cg.org/dashboard/#pr-855
  33. https://qt4cg.org/dashboard/#pr-849
  34. https://qt4cg.org/dashboard/#pr-832
  35. https://qt4cg.org/dashboard/#pr-798
  36. https://qt4cg.org/dashboard/#pr-795
  37. https://qt4cg.org/dashboard/#pr-737
  38. https://qt4cg.org/dashboard/#pr-529
  39. https://github.com/qt4cg/qtspecs/issues/850
  40. https://github.com/qt4cg/qtspecs/issues/829
  41. https://github.com/qt4cg/qtspecs/issues/716
  42. https://github.com/qt4cg/qtspecs/issues/689
  43. https://github.com/qt4cg/qtspecs/issues/583
  44. https://github.com/qt4cg/qtspecs/issues/557
  45. https://github.com/qt4cg/qtspecs/issues/340
  46. https://github.com/qt4cg/qtspecs/issues/260
  47. https://github.com/qt4cg/qtspecs/issues/33
  48. https://github.com/qt4cg/qtspecs/issues/31
  49. https://qt4cg.org/dashboard/#pr-855
  50. https://qt4cg.org/dashboard/#pr-849
  51. https://qt4cg.org/dashboard/#pr-832
  52. https://qt4cg.org/dashboard/#pr-798
  53. https://github.com/qt4cg/qtspecs/issues/829

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 5 December 2023 17:15:59 UTC