QT4 CG draft minutes 018, 17 January 2023

Hi folks,

The draft minutes are online:

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

QT4 CG Meeting 018 Minutes 2023-01-17

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [0/17]
     * [3]1. Administrivia
          + [4]1.1. Roll call [9/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 [5/17]
     * [9]2. Technical Agenda
          + [10]2.1. Review pull request #284: Grammar for if-then w/o
            else
          + [11]2.2. Review pull request #304
          + [12]2.3. Review pull request #290 (function type hierarchy)
          + [13]2.4. Review pull request #286: allow child::(a|b|c)
          + [14]2.5. Issue #299 (formerly #281)
     * [15]3. Any other business

Draft Minutes

Summary of new and continuing actions [0/17]

     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
     * [ ] QT4CG-015-02: NW to improve the width of the diagrams, perhaps
       multiple views
     * [ ] 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.
     * [ ] QT4CG-016-03: RD to add a note clarifying "known character
       encoding"
     * [ ] QT4CG-016-04: RD to add a note clarifying the "*"/"*"
       html/version combination
     * [ ] QT4CG-016-05: RD to add a "todo" noting the dependency on
       keyword arguments
     * [ ] 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-018-01: MK to make a PR that removes ternary expressions.
     * [ ] QT4CG-018-02: MK to review "In this notation, function-name, in
       bold face..." in 1.5.
     * [ ] QT4CG-018-03: MK to address the issues raised in the commeont
       on PR 304
     * [ ] QT4CG-018-04: MK to consider the editorial suggestion on "a
       predicate is not part of a step"

1. Administrivia

1.1. Roll call [9/14]

   Regrets: BTW
     * [ ] Anthony (Tony) Bufort (AB)
     * [X] Reece Dunn (RD)
     * [X] Sasha Firsov (SF)
     * [X] Christian Gr¸n (CG)
     * [ ] Joel Kalvesmaki (JK)
     * [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)
     * [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.

1.4. Next meeting

   The next meeting [18]is scheduled for Tuesday, 24 January 2023.

   No regrets heard.

1.5. Review of open action items [5/17]

     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
     * [ ] QT4CG-015-02: NW to improve the width of the diagrams, perhaps
       multiple views
     * [X] QT4CG-015-03: NW to make sure the direction of the arrow is in
       the legend See PR #308
     * [ ] 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.
     * [ ] QT4CG-016-03: RD to add a note clarifying "known character
       encoding"
     * [ ] QT4CG-016-04: RD to add a note clarifying the "*"/"*"
       html/version combination
     * [ ] QT4CG-016-05: RD to add a "todo" noting the dependency on
       keyword arguments
     * [ ] 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.
     * [X] QT4CG-017-01: MK to clarify the characters numbers in points 1
       and 2 of fn:char
     * [X] QT4CG-017-02: MK to change the order of points to 3, 4, 1, 2 in
       fn:char
     * [X] QT4CG-017-03: SF to follow up on whether or not the browser has
       all the Unicode and emoji names.
          + [19]https://lists.w3.org/Archives/Public/public-xslt-40/2023Ja
            n/0016.html
     * [X] QT4CG-017-04: MK to revise PR #284 to include an optional else
       `else'

2. Technical Agenda

2.1. Review pull request #284: Grammar for if-then w/o else

   See [20]pull request #284. Some discussion [21]last week.
     * MK thinks he had a clear action last week; has updated PR #284
     * MK reviews #284
          + ... MK reviews 4.15, Conditional Expressions
     * MSM: I persuaded myself this wasn't ambiguous because of the
       braces, but I'm worried about an if within an else that isn't
       braced.
     * RD: Do you mean a braced if with a regular if inside it?

   Some attempt to construct an example on the fly...

   At this point, some of the discussion is about examples presented in
   the chat window. The scribe does his best...
     * MSM adds to chat:
       if (condition) { then-clause } else { else-clause }
       but in the case that the else-clause is a conditional, then
       if (condition) { then-clause } if (c2) { then-2 } else {
       else-clause }
     * DN: If we substitute ExprSingle with another IfExpr and another
       unbraced action, then we'll have else ambiguity.
     * RD observes there's a typo in the example
     * MSM: Else ambiguity an only arise if you have conditions in the
       then clause. Let's consider:
       if (condition) { then-clause } else if (c2) { then-2 } else {
       else-clause }
       if (condition) { then-clause } else { if (c2) { then-2 } else {
       else-clause } }
     * MSM: What I was expecting to see required, but is only allowed, is
       that you can put the else clause in a braces.
     * MSM: I was concerned about the first case but I think it's
       unambiguous.
     * MK: The special case of the intermede else-if clauses are only
       allowed a "then" branch, they aren't allowed their own "else"
       branches.
     * RD: One way to view this is that it's kind of similar to switch and
       type-switch statements.
     * MSM: I believe it is in fact unambigous.
     * MK: It requires a single token lookahead but it's unambiguous.
     * RD: Another thing with respect to grammar ambiguity: this pattern
       is common in a lot of languages like C/C++/Java/C#/JavaScript/etc.
     * MSM: Yes, but if you transcribe the grammar for C into clean
       grammar formalism, you will find that they're full of ambiguities!
       They're expecting manually written parsers. There are a lot of ad
       hoc rules and my life is not completely filled with regret that we
       didn't hold the line on ad hoc rules better.
     * RD: There are BNF grammars for C.
     * MSM: Yes, and if you put them through a grammar analysis tool, you
       will find huge amounts of ambiguity. At least I did!

   Some questions about the ambiguity of "C" arise. MSM agrees to dig up
   his notes.

   The group seems satisfied that this is not ambiguous.

   Proposal: Accept this PR.

   Accepted.
     * MK: What is the sentiment of the group about the ternary
       conditional?
     * CG: Now that we have two alternatives for if/then, I could skip
       ternary expressions.

   Some voices of agreement.

   ACTION QT4CG-018-01: MK to make a PR that removes ternary expressions.

2.2. Review pull request #304

   See [22]pull request #304. This is Mike's PR #292 redrafted by Norm.
   Mike writes:

   I regret that this has turned into a bit of an omnibus PR. The main
   changes are:
     * Fix validity issues with the function catalog and its schema (Issue
       291)
     * Convert all functions to use a single signature with optional
       parameters (Issue 70)
     * Extend the function catalog to handle record definitions (Issue
       257)
     * Fix the (trivial) bug with properties of fn:path (Issue 288)
     * Add introductory text concerning the handling of operators (Issue
       35)

   MK reviews PR #304.
     * MK: The primary aim was to change the function signatures.
          + ... For example, fn:string-join has one signature instead of
            two.
          + ... There may need to be more ammendments to the prose if we
            find mentions of particular signatures.
     * MK: I went on to address the title of the document in section 1.1
       Operators.
     * DN: Are all the functions from 3.1 that have more than one overload
       convert to this new format?
     * MK: The vast majority are, but there are one or two that you can't.
       For example, the single-argument form of fn:tokenize doesn't have
       an equivalent form with default arguments.
     * DN: If this is only partially done, we probably need an issue to
       review it.
     * NW: The other thing you mentioned was fn:path
     * MK: That's a simple typo I fixed.
     * JL: Are all the operators functionable now?
     * MK: All the first-order operators are.
     * MSM: In section 1.5 Function signatures and descriptions, strictly
       speaking it's the local name of the function. The name of the
       function is "fn:"-function name.
     * MK: In that paragraph, it should say fn:function-name

   Some discussion of whether it would be better to use fn:function-name
   or to refer to the function-name as the local name.

   ACTION QT4CG-018-02: MK to review "In this notation, function-name, in
   bold face..." in 1.5.
     * MK: I raised some errata in the PR entry, but I propose to fix them
       after the merge.

   ACTION QT4CG-018-03: MK to address the issues raised in the commeont on
   PR 304
     * RD: I think I raise an issue for the "**" in the signature of
       fn:all-different, issue #62

   Proposal: accept this PR

   Accepted.

2.3. Review pull request #290 (function type hierarchy)

   See [23]pull request #290. This PR seems to be against an earlier draft
   so the diff markup is a bit odd. I believe the only intended change is
   the [24]paragraph in 2.9.1 Functions.
     * NW tries to explain his remark about 2.9.1
     * MK: This change corrects the incorrect statement that there's a
       hierarchy of function types. The rules for subtyping functions mean
       that the graph of subtypes of functions isn't a heirarchy. It's
       acyclic but not hierarchic.

   Proposal: accept this PR

   Accepted.

2.4. Review pull request #286: allow child::(a|b|c)

   See [25]pull request #286.
     * MK reviews the PR
          + ... This primarily effects XPath but also impacts XSLT.
          + ... In 4.6.2.2 MK reviews the production changes
          + ... The only other complication is where that fits into the
            grammar.
          + ... There's a change in 4.6.3 about reverse axes
     * JL: Is the union required to be flat in the grammar? I can't
       bracket inside the brackets?
     * MK: Yes, that was a deliberate simplification.
     * MSM: I found the explanation, "the predicate is not part of a step"
       a bit opaque. Would it be clearer to say that the predicate applies
       to the result of a union. That will remind some readers that unions
       sort into document order.

   ACTION QT4CG-018-04: MK to consider the editorial suggestion on "a
   predicate is not part of a step"
     * RD: Thinking about grammatical ambiguities, in addition to applying
       to forward and backwards steps it also applies to abbreviated
       steps.
     * MK: Yes.
          + ... Moves to 4.6.5 to show that you can't have a union node
            test all on it's own.
     * MK: In XSLT...
          + ... It's all about how patterns and precedence interact with
            these changes.
          + ... The default precedence is extended to cover this new case.
     * MSM: Since the union node tests need to be flat, unlike a union
       expression, the union node test will always produce patterns with
       the same priority, no?
     * MK: No, because...
     * JL: Yes, because...

   Some discussion ensues.
     * MK: No, it can be a NameTest and a NameTest can have a wild card.
     * MSM: Right. Thank you.

   Proposal: accept this PR

   Accepted.

2.5. Issue #299 (formerly #281)

   We had [26]some discussion of [27]#281 previously, but no resolution.
   Awaiting more feedback from the CG in the issue.
     * NW: Did you get more feedback?
     * DN: Yes, there was a thread about additional guards. That got
       several informal approvals.
          + ... We made progress in formalizing what lazy means.
          + ... We can have lazy() as a function with a single argument.
          + ... It's body is another function with zero arguments and its
            body is the expression.
          + ... If we a variable of type expression, then the result must
            not be inlined.
          + ... Still waiting for some feedback from RD about laziness on
            a compound structure.
          + ... RD proposed wildcard notation which means we don't need
            other parts of the object.
     * DN: I suggest we leave this open and give other people a chance to
       review.

3. Any other business

References

   1. https://qt4cg.org/meeting/minutes/2023/01-17#minutes
   2. https://qt4cg.org/meeting/minutes/2023/01-17#new-actions
   3. https://qt4cg.org/meeting/minutes/2023/01-17#administrivia
   4. https://qt4cg.org/meeting/minutes/2023/01-17#roll-call
   5. https://qt4cg.org/meeting/minutes/2023/01-17#agenda
   6. https://qt4cg.org/meeting/minutes/2023/01-17#approve-minutes
   7. https://qt4cg.org/meeting/minutes/2023/01-17#next-meeting
   8. https://qt4cg.org/meeting/minutes/2023/01-17#open-actions
   9. https://qt4cg.org/meeting/minutes/2023/01-17#technical-agenda
  10. https://qt4cg.org/meeting/minutes/2023/01-17#pr-grammar-if-then-else
  11. https://qt4cg.org/meeting/minutes/2023/01-17#h-6142CC30-B435-4A23-8FEB-C7C5DAA040DD
  12. https://qt4cg.org/meeting/minutes/2023/01-17#h-E5807567-F254-497C-80BE-B6F7458D3FA7
  13. https://qt4cg.org/meeting/minutes/2023/01-17#h-4A6AF901-EAAE-4483-929B-3C72C53E1685
  14. https://qt4cg.org/meeting/minutes/2023/01-17#h-EF7A6EB3-0BDC-4E8E-A805-8461FD43964C
  15. https://qt4cg.org/meeting/minutes/2023/01-17#any-other-business
  16. https://qt4cg.org/meeting/agenda/2023/01-17.html
  17. https://qt4cg.org/meeting/minutes/2023/01-10.html
  18. https://qt4cg.org/meeting/agenda/2023/01-24.html
  19. https://lists.w3.org/Archives/Public/public-xslt-40/2023Jan/0016.html
  20. https://qt4cg.org/dashboard/#pr-284
  21. https://qt4cg.org/meeting/minutes/2023/01-10.html
  22. https://qt4cg.org/dashboard/#pr-304
  23. https://qt4cg.org/dashboard/#pr-290
  24. https://qt4cg.org/pr/290/xpath-datamodel-40/autodiff.html#function-items
  25. https://qt4cg.org/dashboard/#pr-286
  26. https://qt4cg.org/meeting/minutes/2022/12-13.html#issue-281
  27. https://github.com/qt4cg/qtspecs/issues/281

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 17 January 2023 17:12:29 UTC