QT4 CG draft minutes 020, 31 January 2023

Hi folks,

Apologies again for failing to email the agenda. Here are the draft
minutes from today:

  https://qt4cg.org/meeting/minutes/2023/01-31.html

A text copy:

QT4 CG Meeting 020 Minutes 2023-01-31

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [0/12]
     * [3]1. Administrivia
          + [4]1.1. Roll call [8/14]
          + [5]1.2. Accept the agenda
          + [6]1.3. Approve minutes of the previous meeting
          + [7]1.4. Next meeting
          + [8]1.5. Review of open action items [6/14]
     * [9]2. Technical Agenda
          + [10]2.1. PR #319: Issue 221: op:same-key becomes
            fn:atomic-equal
          + [11]2.2. PR #320: Issue 98 - add options parameter to
            fn:deep-equal
          + [12]2.3. PR #326: Issue 205: make support for higher-order
            functions mandatory
          + [13]2.4. PR #324: Proposed syntax and semantics for string
            templates
          + [14]2.5. PR #308: Improve the legends in the diagrams
     * [15]3. Any other business

Draft Minutes

Summary of new and continuing actions [0/12]

     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
     * [ ] QT4CG-016-02: NW to add an ed-note indicating when it was
       approved.
     * [ ] QT4CG-016-06: RD to reword the introduction to mapping to
       clarify who's doing the mapping
     * [ ] QT4CG-016-07: NW to make an issue about the problems of
       document-uri uniqueness
     * [ ] QT4CG-016-08: RD to clarify how namespace comparisons are
       performed.
     * [ ] QT4CG-016-09: RD to add a note stating that the local name
       should always be lowercase
     * [ ] QT4CG-016-10: RD to consider how to clarify parsed entity
       parsing.
     * [ ] QT4CG-019-01: MK to fix the type of $pattern in fn:tokenize()
     * [ ] QT4CG-020-01: MK to check if the default for type-variety is
       correct.
     * [ ] QT4CG-020-02: MK to review the description of the equal-strings
       function
     * [ ] QT4CG-020-03: MK to add examples using options.
     * [ ] QT4CG-020-03: MK to add an option to return false instead of
       raising an error

1. Administrivia

1.1. Roll call [8/14]

   Regrets: BTW, JK, EP.
     * [ ] Anthony (Tony) Bufort (AB)
     * [X] Reece Dunn (RD)
     * [X] Sasha Firsov (SF)
     * [X] Christian Gr¸n (CG)
     * [ ] Joel Kalvesmaki (JK) [:12-]
     * [X] Michael Kay (MK)
     * [X] John Lumley (JL)
     * [X] Dimitre Novatchev (DN)
     * [ ] Ed Porter (EP)
     * [ ] Liam Quin (LQ)
     * [ ] Adam Retter
     * [X] C. M. Sperberg-McQueen (MSM)
     * [ ] Bethan Tovey-Walsh (BTW)
     * [X] Norm Tovey-Walsh (NW). Scribe. Chair.

1.2. Accept the agenda

   Proposal: Accept [16]the agenda.

   Accepted.

1.3. Approve minutes of the previous meeting

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

   Accepted.

   The agenda and minutes were not sent by email, chair apologizes.

1.4. Next meeting

   The next meeting [18]is scheduled for Tuesday, 7 February 2023.

   No regrets heard.

1.5. Review of open action items [6/14]

     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
     * [X] QT4CG-015-02: NW to improve the width of the diagrams, perhaps
       multiple views
     * [X] QT4CG-015-04: NW to investigate of a dynamic presentation is
       practical
     * [ ] QT4CG-016-02: NW to add an ed-note indicating when it was
       approved.
     * [X] QT4CG-016-03: RD to add a note clarifying "known character
       encoding"
          + [19]https://github.com/qt4cg/qtspecs/pull/330
     * [X] QT4CG-016-04: RD to add a note clarifying the "*"/"*"
       html/version combination
          + [20]https://github.com/qt4cg/qtspecs/pull/330
     * [X] QT4CG-016-05: RD to add a "todo" noting the dependency on
       keyword arguments
          + [21]https://github.com/qt4cg/qtspecs/pull/330
     * [ ] QT4CG-016-06: RD to reword the introduction to mapping to
       clarify who's doing the mapping
     * [ ] QT4CG-016-07: NW to make an issue about the problems of
       document-uri uniqueness
     * [ ] QT4CG-016-08: RD to clarify how namespace comparisons are
       performed.
     * [ ] QT4CG-016-09: RD to add a note stating that the local name
       should always be lowercase
     * [ ] QT4CG-016-10: RD to consider how to clarify parsed entity
       parsing.
     * [ ] QT4CG-019-01: MK to fix the type of $pattern in fn:tokenize()
     * [X] QT4CG-019-02: NW to revisit the width issue in the type
       diagrams

2. Technical Agenda

2.1. PR #319: Issue 221: op:same-key becomes fn:atomic-equal

   See [22]pull request #319. We already have one approval for this PR.

   MK provides a quick summary of the new fn:atomic-equal() function and
   its consequences.
     * DN: If this is the same as op:same-key(); I see some duplication.
     * MK: No, the old function op:same-key() no longer exists.

   Proposal: accept this pull request

   Accepted.

2.2. PR #320: Issue 98 - add options parameter to fn:deep-equal

   See [23]pull request #320. Mike asks especially for careful review,
   this is not a simple change.

   MK proposes to introduce and describe the changes.
     * MK: Add an $options parameter; unfortunately the ~\(collation\)
       parameter can't be merged into it.
          + ... The $options defines how the comparisons are made
          + ... The default values are all aligned with the 3.0 verison of
            the function

   ACTION QT4CG-020-01: MK to check if the default for type-variety is
   correct.
     * MK continues
          + ... Options are designed so that if you set it to true, you
            get stricter comparisions. This explains the name of
            whitespace-retained.
     * RD: Should the unordered comparison option apply to map keys as
       well?
          + MK: Map entries are always unordered...
     * MK: Sequences are deep equal if their items are pair-wise
       deep-equal
     * RD: Should we clarify the order in which fn:normalize-unicode and
       fn:normalize-space are applied.

   ACTION QT4CG-020-02: MK to review the description of the equal-strings
   function
     * MK: It's much the same as before, except where the options come
       into play.
          + ... The unordered-elements option is a bit subtle if you have
            mixed content or if there are multiple elements with the same
            name.
     * JL: So you're on your own if you have text nodes?
     * MK: No, just don't use it if you have text nodes.
     * CG: Should it sort by node type so that it could work with mixed
       content?
     * MK: Could do, but I thought it wasn't going to be useful for mixed
       content.
          + ... Of course, people do use mixed content in strange ways due
            to changes over time.
     * MK: Type variety is a little more complex because it has to
       describe what's meant by complex content and simple content.
          + ... The logic for how we compare complex and simple content is
            preserved.

   ACTION QT4CG-020-03: MK to add examples using options.
     * RD: Would be nice to see examples based on intended usage, like
       around comparing two items in a unit test style.
     * MK: I don't want to go into enormous detail on use cases.
     * DN: We have several functions where one of the parameters is a
       comparison function. In order to use deep-equal we need an option
       to return false instead of raising an error if an error occurs.
     * MK: The only error condition is if there's a function item; we
       simply don't have a way of sensibly comparing function items.
     * DN: Just return false.
     * MK: But that would make a sequence not-equal to itself.
     * DN: We can just spell out that it only equals itself if it contains
       no function items.
     * MK: Where we talk about functions being deterministic, we claim
       processors can sometimes tell.
     * DN: I'm not saying deep-equal should never return an error, just
       that it should be an option.

   ACTION QT4CG-020-03: MK to add an option to return false instead of
   raising an error
     * DN: If we don't return errors for the same conditions, we're losing
       some backwards compatibility

   Some discussion of whether or not comparison of typed element content
   can raise an error.
     * DN: I seem to recall that in the old version items were compared
       with the "=" value so that times with and without timezones
       couldn't be compared.
     * MK: I'll investigate that.
     * RD: In the context of using this for things like implementing unit
       test assertions, one of the things I found useful for diagnostics
       was having the location where the failure occurred. Should we have
       an option to do that?
     * MK: My plan was to add an fn:differences function that returns the
       differences, rather than just returning true or false.
     * RD: Tangentially related fn:path only works for nodes. Should we
       extend it to maps and arrays?
     * MK: Maybe,
     * CG: Do we need the debug option if we have fn:differences?
     * MK: Let's wait and see.
     * DN: In case where there are unordered elements and there are
       multiple groups with individuals that are the same, what is the
       order of the comparisons?
     * MK: The current rule is very simple, simplistic even, it says you
       sort them by namespace and local name, and then you compare them.
       If you have multiple elements with the same name, their order is
       going to be significant.
     * JL: What happens if the child elements themselves are in unordered
       sets?
     * MK: The options are passed down.
     * DN: I think this is a bit confusing?
     * MK: Maybe I should change it to do a pure pair-wise set-comparison.
     * DN: Yes.
     * DN: Have you considered an implementation that just makes hashes
       and compares the hashes?
     * MK: Yes, that's the sort of thing. It's note easy but it can be
       done.
     * MSM: Question about the rule that says there's a mapping, are you
       envisioning a 1:1 mapping or just that there is a mapping.
     * MK: I was phrasing it as there must be a pairing: an ordering of A
       and B such that they are pairwise equal.
     * MSM: So an empty element named E will not match in this comparison
       a sequence of 3 empty elements all named E.
     * MK: No.

2.3. PR #326: Issue 205: make support for higher-order functions mandatory

   See [24]pull request #326. We already have one approval for this PR.
     * MK: In the current specs, support for higher order functions is
       optional. That's not really viable anymore. All of the 3.1
       implmentations we know about already support it.
     * JL: Does that mean you have to implement all the HoF?
     * MK: Yes.
     * MSM: Is it really true? I thought eXist didn't.
     * MK: They don't claim to be 3.1, do they?
     * CG: I thought eXist did.
     * MK: We're defining so much functionality with HoF that you really
       have to implement them.

   Some discussion of eXist's support.
     * MK: Making a feature mandatory doesn't mean everyone will implement
       it!
     * MSM: True, it just makes comparing conformance easier.
     * MK: It also means it allows users to use features that they might
       not if it was optional.

   Proposal: accept this PR

   Accepted.

2.4. PR #324: Proposed syntax and semantics for string templates

   See [25]pull request #324. We already have one approval for this PR.

   MK reviews the XQuery version.
     * MK: I moved string constructors and string concatenation into the
       same section.
          + ... Proposed syntax is to use backtick delimited strings.
          + ... The fixed part is just what it says, with escaped
            delimiters unescaped.
          + ... The variable part works like attributes in XQuery (but not
            exactly like XSLT, unfortunately)
          + ... That's it, except for a few complications.
          + ... One complication is that ampersands are treated slightly
            differently.
          + ... There's also a tokenization ambiguity: ``[1]. It's
            resolved in favor of string constructor on the longest token
            rule.
     * MK: If we didn't have that rule, then XPath and XQuery would behave
       differently.
     * DN: In other programming languages, this is called "string
       interpolation", maybe we should use the same term.
     * DN: I think there could be more than one variable part in a string
       interpolation, but the prose suggests that there can be only one.
     * MK: It certainly can be more than one, as the syntax makes clear.
     * DN: Okay, maybe there should be at least one example with more than
       one variable part.
     * MK: That's already true!
     * CG: The name "template" is more familiar to me, it's like
       JavaScript.
     * MK: Yes, languages have different names for the same thing but
       slightly different syntaxes.
     * RD: The XSLT spec already uses "attribute value templates" and
       "text value templates".
     * MK: We could call this "string value templates" if we really wanted
       to.
     * RD: I think internal consistency is more important than consistency
       with other languages.
     * MK: The thing I always ask myself is, if someone comes across this
       term in an error message and hasn't read the spec, are they going
       to guess correctly what it's referring to.
     * SF: They're called "template literals" in JavaScript. In others
       they're called by different names.
     * MK: I don't want to cause it a literal because it's an expression.
     * DN: I wasn't trying to force another name, I just thought it would
       be useful to mention "string interopolation" in the prose.
     * SF: We should include "string interpolation" and "template
       literals".

   Proposal: accept this PR

   Accepted.

2.5. PR #308: Improve the legends in the diagrams

   See [26]pull request #308.

   NW introduces the changes.
     * NW: Last week, several folks said these should just be lists. So I
       just made them lists!
     * RD: Would it be possible to move the legend to the right?
     * NW: I'll see what I can do.

   Proposal: accept this PR

   Accepted.

3. Any other business

     * RD requests issue #307 for the agenda next week.

References

   1. https://qt4cg.org/meeting/minutes/2023/01-31.html#minutes
   2. https://qt4cg.org/meeting/minutes/2023/01-31.html#new-actions
   3. https://qt4cg.org/meeting/minutes/2023/01-31.html#administrivia
   4. https://qt4cg.org/meeting/minutes/2023/01-31.html#roll-call
   5. https://qt4cg.org/meeting/minutes/2023/01-31.html#agenda
   6. https://qt4cg.org/meeting/minutes/2023/01-31.html#approve-minutes
   7. https://qt4cg.org/meeting/minutes/2023/01-31.html#next-meeting
   8. https://qt4cg.org/meeting/minutes/2023/01-31.html#open-actions
   9. https://qt4cg.org/meeting/minutes/2023/01-31.html#technical-agenda
  10. https://qt4cg.org/meeting/minutes/2023/01-31.html#h-0BCF3769-7D91-45D1-8D2E-12E48F9E6757
  11. https://qt4cg.org/meeting/minutes/2023/01-31.html#h-8455483D-D0AF-499A-A74A-552B33A9F395
  12. https://qt4cg.org/meeting/minutes/2023/01-31.html#h-C5A6E1C0-5D39-44D5-AEE5-C31BB5386E20
  13. https://qt4cg.org/meeting/minutes/2023/01-31.html#h-F2F35033-A57A-4FE6-B7ED-CF7A4B15983D
  14. https://qt4cg.org/meeting/minutes/2023/01-31.html#h-7C58A4CA-1101-4222-A9D8-4304E75F0B76
  15. https://qt4cg.org/meeting/minutes/2023/01-31.html#any-other-business
  16. https://qt4cg.org/meeting/agenda/2023/01-31.html
  17. https://qt4cg.org/meeting/minutes/2023/01-24.html
  18. https://qt4cg.org/meeting/agenda/2023/02-07.html
  19. https://github.com/qt4cg/qtspecs/pull/330
  20. https://github.com/qt4cg/qtspecs/pull/330
  21. https://github.com/qt4cg/qtspecs/pull/330
  22. https://qt4cg.org/dashboard/#pr-319
  23. https://qt4cg.org/dashboard/#pr-320
  24. https://qt4cg.org/dashboard/#pr-326
  25. https://qt4cg.org/dashboard/#pr-324
  26. https://qt4cg.org/dashboard/#pr-308

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 31 January 2023 17:19:15 UTC