QT4 CG Meeting 011 draft minutes 2022-11-15



QT4 CG Meeting 011 Minutes 2022-11-15

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [1/8]
     * [3]1. Administrivia
          + [4]1.1. Roll call [10/13]
          + [5]1.2. Accept the agenda
          + [6]1.3. Next meeting
          + [7]1.4. Approve minutes of the previous meeting
          + [8]1.5. Review of open action items [7/8]
          + [9]1.6. Merging PRs that are accepted in principle
          + [10]1.7. Meeting logistics
     * [11]2. Technical Agenda
          + [12]2.1. Review pull request #197 (was 166; variadic
          + [13]2.2. Review pull request #210: Issue 80: fn:while
          + [14]2.3. Review pull request #202 (was 196; subtyping)
          + [15]2.4. Review pull request #207: new expanded-QName function
          + [16]2.5. Review pull request #215: parse-uri/build-uri
          + [17]2.6. Review pull request #222: sequence comparisons
          + [18]2.7. Review pull request #228: make F&O spec valid XML
          + [19]2.8. Review pull request #230: guarded expressions, issue
     * [20]3. Any other business

Draft Minutes

Summary of new and continuing actions [1/8]

     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
     * [ ] QT4CG-011-01: MK to fix the reference to "function" in XPath
     * [ ] QT4CG-011-02: CG to work with DN to propose an "until" variant.
     * [ ] QT4CG-011-03: MK to change the references to URI qualified name
       in both QName-related functions.
     * [ ] QT4CG-011-04: NW to define the parse-uri/build-uri record types
       in a separate section
     * [ ] QT4CG-011-05: NW to update the history for parse-uri/build-uri
       to indicate that details are still being resolved
     * [ ] QT4CG-011-06: NW to make sure ednotes are rendered.
     * [X] QT4CG-011-07: NW to make sure the meeting passcode is on the
       logistics page
          + This is already the case

1. Administrivia

1.1. Roll call [10/13]

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

1.2. Accept the agenda

   Proposal: Accept [21]the agenda.


1.3. Next meeting

   The next meeting [22]is scheduled for Tuesday, 22 November.

   Regrets: JL for 22 and 29 November.

1.4. Approve minutes of the previous meeting

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


1.5. Review of open action items [7/8]

   (Items marked [X] are believed to have been closed via email before
   this agenda was posted.)
     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
     * [X] QT4CG-007-05: NW to make an issue for Martin's proposed
       ammendment to map:build
          + See [24]issue #236.
     * [X] QT4CG-008-04: MK to submit a PR for fn:parseQName() to resolve
       PR #207
          + Mike reports the action is complete in PR #207
     * [X] QT4CG-009-01: NW to coordinate with MK on an agenda for 8
     * [X] QT4CG-009-02: NW to work with MK to make sure PR #197 is
       updated correctly
     * [X] NW to update PR #215
          + [X] QT4CG-009-03: NW to investigate the relationship between
            PR #215 and resolve-uri.
          + [X] QT4CG-009-04: NW to review RFC 3896 wrt relative URIs
          + [X] QT4CG-009-05: NW to fix the return type for parse-uri;
            consider using a record type.
          + [X] QT4CG-009-06: NW to add error tests for parse-uri.
          + [X] QT4CG-009-07: NW to make the query segments an array of
     * [X] QT4CG-010-01: DN to create an issue for proposing an optional
       else in XPath/XQuery
     * [X] QT4CG-010-02: MK to incorporate the suggestions made by MSM on
       @then/@else on xsl:if
          + [25]https://lists.w3.org/Archives/Public/public-xslt-40/2022No

1.6. Merging PRs that are accepted in principle

   We've been keeping PRs open while detailed comments are worked out. I
   think that's a fine model, but it has the consequence that we end up
   with a lot of PRs open for a long time. That increases the chances that
   we'll create merge conflicts, making our life more difficult later, and
   means that there are many slightly different copies of each spec to

   I propose that we agree to merge PRs as soon as the group feels that
   the proposal is complete enough to accept in principle. We can add a
   note in the history (for functions, at least) that it's provisionally
   accepted until detailed comments are resolved, or words to that effect.

   In the very short term, I would especially like to merge all of the PRs
   that are open against F&O so that the XML validity errors and the new
   markup for "type references" can be sorted out.
     * RD: That makes sense
     * JL: Where do discussions happen?
     * NW: I think we get discussion in the issues until there's a PR,
       then on the PR.
     * MSM: In groups that I have been in that use a two-pass approach,
       the point of not considering things changed until the wording is
       all correct, one side effect is that if there are minor side
       effects in the wording, if we merge earlier, is there a way to
       ensure that nits don't fall under the table?
     * MK: I've usually seen that managed through actions
     * MSM: Okay.
     * NW: At least in F&O, we have a history section where we can observe
       that it's unresolved.
     * MK: XMLSpec also has an ednote; we could render them.

   ACTION QT4CG-011-06: NW to make sure ednotes are rendered.

   Proposal: merge PRs when they're accepted in principle.


1.7. Meeting logistics

   DN observes that he had trouble getting into the meeting. There was a
   different Zoom link and passcode last week and, for some reason, Zoom
   asked DN for a passcode this week.

   ACTION QT4CG-011-07: NW to make sure the meeting passcode is on the
   logistics page

2. Technical Agenda

2.1. Review pull request #197 (was 166; variadic functions)

     * See [26]pull request #197 (you'll find links to formatted versions
       of the specs at [27]https://qt4cg.org/).
     * See also the nexus of issues [28]#162, [29]#161, [30]#160,
       [31]#159, [32]#158, [33]#157, and [34]#155.
     * See the discussion from [35]meeting 006, [36]meeting 007, and
       [37]meeting 008.

   NW updated the PR with MK's most recent changes.

   We hope to resolve this PR this week.
     * MSM: I noticed that somewhere in the middle, some of the new text
       uses the unqualified term "function" and it caught my eye partly
       because early on in this pull requestion there's a note that we use
       the term "function item". Was that change intentional, or does it
       need a tweak?
     * MK: This crosses a couple of PRs. The Data Model uses the term
       "function" to mean an item. I've for the moment stuck to that, but
       I've also proposed changing it otherwise it gets too confused with
       static functions which aren't function items.
     * MSM: I had the impression that in a lot of cases in this PR we were
       using function item.
     * MK: Yes, but it's probably not uniformly applied.
     * MSM: I'm pretty sure that the bit that caught my eye was "apropos
       of lookup" where there's a reference that's neither to a function
       definition or a function item, just a "function".

   Subsequent discussion reveals that the editor thinks the sentence is
   (too?) informal.

   ACTION QT4CG-011-01: MK to fix the reference to "function" in XPath
     * RD: Looking through the grammar, the function signature with
       defaults is a sequence of param with defaults with optional default
       values. So according the grammar you can interleave optional and
       non-optional parameters. But elsewhere we say that required ones
       have to come first.
     * MK: I decided to make that an extra-grammatical rule.
     * RD: That makes sense, the grammar is difficult to get right.
     * NW: An action to add it to A.1.2?
     * MK: No, I don't think that's necessary. We have too many
       constraints like this that aren't mentioned.

   Proposal: Accept this PR?


2.2. Review pull request #210: Issue 80: fn:while

     * See [38]pull request #210 and the [39]minutes of two weeks ago.

   We hope to resolve this PR this week.
     * CG: I renamed the function from fn:while to fn:iterate-while per
       DN. Most use cases can be realized with this function, so I haven't
       explored the until variant.
     * MSM: The one question I have relates to a remark that MK made. If
       you want to generate a sequence of items until something happens,
       is there a way to do that using fn:iterate-while. This isn't a
       reason not to accept the proposal, I'm just curious.
     * CG: I think it's absolutely possible, you can generate any kind of
       data structure you want. You can pass the sequence along, etc.

   Proposal: Accept this PR?
     * DN: I think that it would be good to discuss fn:iterate-until now.
     * MK: Do we have a spec for fn:iterate-until?
     * MSM: How would it be different?
     * DN: The condition is just the opposite condition.
     * CG: We also talked about having the action performed at least once.
       Then we wouldn't need to negate the predicate.
     * MK: Point of order: there's no proposal for this.

   ACTION QT4CG-011-02: CG to work with DN to propose an "until" variant.

   Proposal: Accept this PR?


2.3. Review pull request #202 (was 196; subtyping)

   See [40]pull request #202
     * MK: The principle changes are to the section on defining subtyping
       rules. There were two major comments on the original proposal: lots
       of good detail from RD and a question of the fundamental nature of
       atomic values from MSM. I propose to address the latter in a
       different issue.
          + ... This primarily addresses the subtyping rules that are
            common between XPath and XQuery.
     * NW: The diffs are awful, they don't deal with the notation changes.
     * MK: Where RD raised technical questions, I've managed to persuade
       myself that it's only more explicit.
     * RD: I'm happy with the changes. The only minor thing is that in the
       generated output, the example blocks don't have the proper styling.
     * MSM: An editorial point, hopefully not a bike-shedding issue, you
       are using the notation "itemtype-subtype" with two arguments as a
       more verbose way of notating the subtype relation. But my instinct
       is that if you are going to name a binary relation for the types or
       roles of its arguments, the order of the name should be the same as
       the name of the arguments. So, change the order or change the name
       to "subtype-itemtype"
     * MK: I kept the function notation basically in case people refer to
     * MSM: So that pseudo function with its backwards arguments, as I see
       it, is a ship that has sailed.
     * MK: Yes. And it always confused me which is why I got rid of it.

   Proposal: Accept this PR?


2.4. Review pull request #207: new expanded-QName function

   See [41]pull request #207
     * RD: The spec references braced URI literal, which is the "U{" part
       of the construct. What it needs to be is the "URI qualified name"
       instead. That's the "Q{}local-name".
     * MK: Uhm...
     * RD: If you look at the expanded QName section.
     * MK: Yes, you're right.
     * MSM: I think there's another place where braced URI literal is
       referred to that should perhaps be expanded QName. I'm looking at
       F&O section 10.1.2 under fn:parse-QName().

   ACTION QT4CG-011-03: MK to change the references to URI qualified name
   in both QName-related functions.
     * MK: In the last paragraph, the reference to BracedURILiteral is ok.

   Proposal: Accept the PR?


2.5. Review pull request #215: parse-uri/build-uri

   See [42]pull request #215

   Waiting on actions QT4CG-009-0{3,4,5,6,7} on NW.
     * RD: Make a separate subsection like RegEx pattern and point to it
       from both places.

   ACTION QT4CG-011-04: NW to define the parse-uri/build-uri record types
   in a separate section

   ACTION QT4CG-011-05: NW to update the history for parse-uri/build-uri
   to indicate that details are still being resolved

2.6. Review pull request #222: sequence comparisons

   See [43]pull request #222

   Accepted at [44]meeting 009, waiting for MK to resolve a merge

2.7. Review pull request #228: make F&O spec valid XML

   See [45]pull request #228

   Approved by RD, waiting for open PRs on F&O to be accepted, then NW
   will resolve any merge conflicts that arise and commit it.

   Proposal: Accept the PR (after resolving merge conflicts)?


2.8. Review pull request #230: guarded expressions, issue #71

   See [46]pull request #230 and related [47]issue #71.

   Approved by CG.
     * MK: The section on errors and optimization, which was always
       troublesome, gives implementations an awful lot of license to
       rearrange expressions in ways that introduce and eliminate errors.
       There's a very limited set of exceptions for conditional
       expressions. What this does is take out that text for conditional
       expressions from 2.3.4 and generalize it into the concept of
       guarded expressions in 2.3.5. It gives similar guarantees for a
       number of other cases: "and" and "or" expressions where it says the
       first is guarded by the second; the same for multiple predicates,
       they behave like "and".
          + ... It also says that for loops, if you pull something out of
            the loop, it can't raise an error if the loop is executed zero
     * MSM: I'm not up to speed on this, if I've understood correctly, the
       upshot is that implementations can still reorder things, but if the
       reordered code raises an error, you have to work out if it would
       have raised the error in the original order.
     * JL: Why is this in XQuery instead of XPath?
     * MK: It's in both.
     * DN: I fully support this, but it just touches on the surface and we
       need to consider the topic of short circuit operators. Many
       languages have short circuiting operators. Maybe we can consider
       allowing the programmer to specify hints about possible lazy
     * MK: I'm very conscious that the whole treatment of error handling
       is still extremely informal and this is a small step in the
       direction of making it a bit more formal. Unfortunately, I'm not a
       formalist. It would be nice to have someone who could really do the
       formal semantics of error handling much more thoroughly.
          + ... With respect to lazy evaluation, we've done hints before
            (ordered vs unordered) and they've been spectacularly
            unsuccessful. Implementors ignore them, users don't understand
            them, so I have doubts about hints are likely to be of
            widespread benefit.
     * RD: There is a formal semantics for XPath/XQuery 1.0 but that got

   Proposal: Accept this PR?


3. Any other business

   None heard.


   1. https://qt4cg.org/meeting/minutes/2022/11-15.html#minutes
   2. https://qt4cg.org/meeting/minutes/2022/11-15.html#new-actions
   3. https://qt4cg.org/meeting/minutes/2022/11-15.html#administrivia
   4. https://qt4cg.org/meeting/minutes/2022/11-15.html#roll-call
   5. https://qt4cg.org/meeting/minutes/2022/11-15.html#agenda
   6. https://qt4cg.org/meeting/minutes/2022/11-15.html#next-meeting
   7. https://qt4cg.org/meeting/minutes/2022/11-15.html#approve-minutes
   8. https://qt4cg.org/meeting/minutes/2022/11-15.html#open-actions
   9. https://qt4cg.org/meeting/minutes/2022/11-15.html#merging-prs
  10. https://qt4cg.org/meeting/minutes/2022/11-15.html#meeting-logistics
  11. https://qt4cg.org/meeting/minutes/2022/11-15.html#technical-agenda
  12. https://qt4cg.org/meeting/minutes/2022/11-15.html#pr-variadic-functions
  13. https://qt4cg.org/meeting/minutes/2022/11-15.html#pr-fn-while
  14. https://qt4cg.org/meeting/minutes/2022/11-15.html#pr-subtyping
  15. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-743C4A9D-BAEF-4C75-A412-BDFAA9C89856
  16. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-11CAAAFD-8175-4D10-83FA-BEC6AA3312A6
  17. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-04B58DC1-A005-4AD5-83F0-B3BCE110FB76
  18. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-37009862-494E-4CCE-9FA7-DE5B2E9F8474
  19. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-A132F93F-0414-4495-A868-A7F32A6D642A
  20. https://qt4cg.org/meeting/minutes/2022/11-15.html#any-other-business
  21. https://qt4cg.org/meeting/agenda/2022/11-15.html
  22. https://qt4cg.org/meeting/agenda/2022/11-22.html
  23. https://qt4cg.org/meeting/minutes/2022/11-08.html
  24. https://github.com/qt4cg/qtspecs/issues/236
  25. https://lists.w3.org/Archives/Public/public-xslt-40/2022Nov/0013.html
  26. https://qt4cg.org/dashboard/#pr-197
  27. https://qt4cg.org/
  28. https://github.com/qt4cg/qtspecs/issues/162
  29. https://github.com/qt4cg/qtspecs/issues/161
  30. https://github.com/qt4cg/qtspecs/issues/160
  31. https://github.com/qt4cg/qtspecs/issues/159
  32. https://github.com/qt4cg/qtspecs/issues/158
  33. https://github.com/qt4cg/qtspecs/issues/157
  34. https://github.com/qt4cg/qtspecs/issues/155
  35. https://qt4cg.org/meeting/minutes/2022/10-11.html#pr-variadic-functions
  36. https://qt4cg.org/meeting/minutes/2022/10-18.html#pr-variadic-functions
  37. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-variadic-functions
  38. https://qt4cg.org/dashboard/#pr-210
  39. https://qt4cg.org/meeting/minutes/2022/11-01.html#pr-fn-while
  40. https://qt4cg.org/dashboard/#pr-202
  41. https://qt4cg.org/dashboard/#pr-207
  42. https://qt4cg.org/dashboard/#pr-215
  43. https://qt4cg.org/dashboard/#pr-222
  44. https://qt4cg.org/meeting/minutes/2022/11-01.html
  45. https://qt4cg.org/dashboard/#pr-228
  46. https://qt4cg.org/dashboard/#pr-230
  47. https://github.com/qt4cg/qtspecs/issues/71

                                        Be seeing you,

Norm Tovey-Walsh

Received on Tuesday, 15 November 2022 18:01:28 UTC