QT4 CG meeting 015 draft minutes, 2022-12-13

Hello,

I’ve posted the draft minutes:

   https://qt4cg.org/meeting/minutes/2022/12-13

QT4 CG Meeting 015 Minutes 2022-12-13

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [0/7]
     * [3]1. Administrivia
          + [4]1.1. Roll call [7/14]
          + [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 [3/4]
     * [9]2. Technical Agenda
          + [10]2.1. Issue 281
          + [11]2.2. Review pull request #258: add array:index-where
            (issue #114)
          + [12]2.3. Review pull request #259: parse-html (issue #74)
          + [13]2.4. Review pull request #261: fn:char (issue #121)
          + [14]2.5. Review pull request #268: type diagrams (issue #265)
          + [15]2.6. Review pull request #279: Rewrite XSLT ß10.3.4
            (function overriding) for clarity
          + [16]2.7. Review pull request #284: Grammar for if-then w/o
            else
          + [17]2.8. Issue #170, XPath "otherwise" operator
          + [18]2.9. Issue #114, array:index-where
          + [19]2.10. Issue #107, allow self::(a|b|c)
     * [20]3. Any other business
     * [21]4. Adjourned

Draft Minutes

Summary of new and continuing actions [0/7]

     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
     * [ ] QT4CG-014-01: MK to propose new try-get functions for arrays,
       maps, and (maybe) sequences
     * [ ] QT4CG-015-01: MK to change the name of the argument to
       array:index-where from $input to $array
     * [ ] QT4CG-015-02: NW to improve the width of the diagrams, perhaps
       multiple views
     * [ ] QT4CG-015-03: NW to make sure the direction of the arrow is in
       the legend
     * [ ] QT4CG-015-04: NW to investigate of a dynamic presentation is
       practical
     * [ ] QT4CG-015-05: MK to raise a PR to resolve issue #107,
       self::(a|b|c)

1. Administrivia

1.1. Roll call [7/14]

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

   Welcome Sasha Firsov. A brief round of introductions.
     * SF: I'm trying to be an open source contributor and web developer.
       Doing architectural work, trying to put some work on W3C in order
       to make decorated web applications a thing. When multiple
       applications from different vendors meet on the same page, there
       are technologies we need. Transformation is an essential part of
       that. I'm hoping to make a bridge between HTML DOM and XSLT
       communities.
     * NW: Works for Saxonica. Been doing XML since there was XML. I
       worked on the XProc specification.
     * JL: Spent seven years working for Saxonica. Wrote the XSLT compiler
       and XPath 3 compiler.
     * MSM: Got interested in declarative markup in the late 1980s. Worked
       on XML. Worked for W3C for a decade. Spent time on various working
       groups.
     * MK: I haven't been in the game as long as NW and MSM, only about 20
       years. I've beeen developing Saxon all that time and became editor
       of the XSLT spec on version 2.0.
     * DN: I have been active in the XML space for maybe 20 years. Maybe
       I'm most well known for the FXSL library for XSLT 1.0 then 2.0. Did
       some presentations at conferences. I represented Microsoft on the
       XSLT WG, but for the last 10 years I've been actively pushing for
       pure XPath programming. You can see more about me by looking at the
       proposals I've submitted.

1.2. Accept the agenda

   Proposal: Accept [22]the agenda.
     * NW: We'll skip the parse-html PR in RD's absence.
     * DN: Two meetings ago, I was tasked with an action item, to clarify
       the way function arguments are evaluated when a function returns a
       function. I'd like to talk about issue #281.

   Accepted with those amendments.

1.3. Next meeting

   The next meeting [23]is scheduled for Tuesday, 20 December.

   No regrets heard.

   Reminder, the CG Will not meet on 27 December or 3 January.

1.4. Approve minutes of the previous meeting

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

   Accepted.

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

     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
          + Continued
     * [ ] QT4CG-014-01: MK to propose new try-get functions for arrays,
       maps, and (maybe) sequences
          + Continued
     * [X] QT4CG-014-02: MK to draft a spec for array:exists() and
       array:empty() functions
     * [X] QT4CG-014-03: MK to update PR #250 with the new names

2. Technical Agenda

2.1. Issue 281

     * DN: Consider [25]this comment on the issue: if, in $f($x)($y), is
       it possible for $y to be evaluated before $f($x)? If $f($x) returns
       a constant function, is it still possible for $y to be evaulated?
       What do the current rules say?
     * MK: I'm reading section 4.4.2.1, evaluating dynamic function calls.
       Step 1 is to evaluate the base expression, $f($x) to get a
       function, then we ask if the arity matches the number in the
       argument list. It doesn't so we raise a type error. Step 2 says
       that we evaluate the arguments. I think in a numbered list we
       assume the items are performed in the order of the list.
     * DN: There were new rules for coertion which were proposed.
       According to those rules, a type error would not be raised.
     * MK: There's no coercion here because we're not binding the result
       to a variable or function argument.
     * DN: But this is the result of the function, and coercion rules
       apply there too. So we're expecting a 1 argument function and we
       get a 0 argument function. That would be wrapped in a function.
     * MK: That would be true if they were applied, but I don't think they
       are.
     * MSM: You're (DN) saying that $f($x) is supposed to be a one
       argument function, then we'll coerce it to be one. But we can't
       know that here, so we won't coerce it. Do we have a declaration for
       $f that it is a one argument function that returns a one argument
       function?
     * DN: My understanding is, the way the expression is written, it
       expects the evaulation of $f to return a one argument function. My
       understanding is that if it returns a constant function, we
       shouldn't throw an arity expression. Maybe we should add a rule
       that there is no arity exception. This is explicitly writing a
       partial function evaluation.
     * SF: It's about integrity of the language. There are a few different
       things. If $f returns another function or "none", we could make the
       evaluation of $y conditional on that invocation. Consider
       JavaScript's "?.". Do you want $x and $y both to be evaluated?
       That's a question for the programmer. If you do want to evaluate
       both, you would create a function that will accept arguments $x and
       $y, then invoke $f inside that. Quite often folks in software
       development, use the arguments just to assure that it's evaluated.
       In JavaScript, you can use a comma separator which means everything
       will be evaluated.
     * DN: If you could add your comment to this thread, that might be
       easier to understand. I just wanted to pose the question, I think
       the right answer is that $y shouldn't be evaluated until the result
       of $f is returned.
     * NW: I thought Mike's prose was clear about the order, but it's
       unclear about the arity.
     * MSM: Do we do lists in order?
     * MK: It's certainly true that if the first raises an error, you
       don't do the second.
     * MSM: Unless otherwise specified, shouldn't an implementation be
       allowed to evaluate $y greedily?
     * MK: We don't have that level of formality in the specifications.
     * DN: I think this particular example should be in the specification.
     * NW: Let's take this up again next week. Several folks who commented
       on the thread aren't here today.
     * JL: I've been looking at 4.4.4, the function coercion rules, is DN
       suggesting that the type of the left hand thing is determined by
       the existence of the argument. Because it has a single arity, he's
       implying that the function coercion rules apply, and I can't see
       that.
     * DN: I've asked several times, if the coercion rules apply only to
       the function or to the return value. I've been consistently told
       that it applies to the return.
     * MK: But they only apply where there's a declared required type. In
       this case, there's an implicit requirement (like a + operator
       implicitly requires a number), but there isn't an explicit type.
     * DN: Then my proposal is to think about changing the rules, because
       I think this is only logical. Why should we make any kind of
       exclusion from the rules here?
     * MK: It's a tenable situation, we could apply that rule here.
     * MSM: If we declare $f as an arity one function that returns an
       arity one function, then presumably the coercion rules do apply.
     * DN: This seems like casting in C#.

   Some further discussion of how the new corecion rules apply before
   breaking off until next week.

2.2. Review pull request #258: add array:index-where (issue #114)

   See [26]pull request #258

   Mike leads us through the change.
     * MK: There was a comment that $input should be named $array.

   ACTION QT4CG-015-01: MK to change the name of the argument to
   array:index-where from $input to $array

   Proposal: accept this PR with the name change.

   Accepted.

2.3. Review pull request #259: parse-html (issue #74)

   See [27]pull request #259

   Skipped this week.

2.4. Review pull request #261: fn:char (issue #121)

   See [28]pull request #261

   Skipped this week.

2.5. Review pull request #268: type diagrams (issue #265)

   See [29]pull request #268

   Norm introduces the diagrams.
     * MK: It would be nice if they were scaled to fit.
     * NW: Yes, but then they'd illegible.
     * SF: There are other techniques that could be used to make them fit.
     * NW: Yes, but these are generated, so manual positioning isn't a
       practical option.
     * DN: How about rotating the wide one 90 degrees?
     * NW: Maybe. But only if we rotate the text too, otherwise the first
       row is too wide.
     * MSM: Two suggestions and a question. For the first figure, make the
       lgend verical. The secondl ooks promising to me, I think you might
       be able to get what you need by specifying three ranks. My question
       is, what is the meaning of the directional arrow? I wonder if
       people will find it more intiutive if the arrow meant
       is-the-parent-of/basetype-of and went the other way.
     * NW: I did it that way because thaty's the way they were in 3.1.

   Some discussion of UML conventions.
     * MSM: I think arrows going the other way would be a little more
       intuitive, but the meaning of the directional arrow should be in
       the legend.
     * MK: UML does them that way, whether you like it or not
     * MSM: Okay.
     * JK: Maybe just do an XML tree for the really wide diagram?

   Proposal: these diagrams are an improvement, accept this PR

   Accepted

   ACTION QT4CG-015-02: NW to improve the width of the diagrams, perhaps
   multiple views ACTION QT4CG-015-03: NW to make sure the direction of
   the arrow is in the legend
     * DN: There are a number of JavaScript controls that provide
       expanding and collapsing.

   ACTION QT4CG-015-04: NW to investigate of a dynamic presentation is
   practical

2.6. Review pull request #279: Rewrite XSLT ß10.3.4 (function overriding) for
clarity

   See [30]pull request #279
     * MK: This is just an attempt to clarify the presentation; there
       aren't any tehcnical changes.
          + ... We've taken a section that bundled together three things
            about overriding and made them separate.
          + ... There are rules about package import precedence, extension
            functions, and then override in a used package.

   Proosal: Accept this PR.

   Accepted.

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

   See [31]pull request #284

   Skipped this week.

2.8. Issue #170, XPath "otherwise" operator

   MK [32]proposes that [33]this issue may be ready to be decided.
     * MK: Does anyone remember why we postponed this issue? There's no
       explicit action waiting to be done.

   No, we don't. NW to make sure it's higher on the agenda next week.

2.9. Issue #114, array:index-where

   MK [34]proposes that [35]this issue may be ready to be decided

   Resolved by the earlier PR.

2.10. Issue #107, allow self::(a|b|c)

   MK [36]proposes that [37]this issue may be ready to be decided.
     * MK: Is this worth doing? I don't want to spend the time on the PR
       unless there's general agreement that it's a good idea.
     * MSM: How much violence does this do to the grammar?
     * MK: Not much, it just allows a union.
     * MSM: As long as we can be sure it isn't ambiguious.

   ACTION QT4CG-015-05: MK to raise a PR to resolve issue #107,
   self::(a|b|c)

3. Any other business

   None heard.

4. Adjourned

References

   1. https://qt4cg.org/meeting/minutes/2022/12-13#minutes
   2. https://qt4cg.org/meeting/minutes/2022/12-13#new-actions
   3. https://qt4cg.org/meeting/minutes/2022/12-13#administrivia
   4. https://qt4cg.org/meeting/minutes/2022/12-13#roll-call
   5. https://qt4cg.org/meeting/minutes/2022/12-13#agenda
   6. https://qt4cg.org/meeting/minutes/2022/12-13#next-meeting
   7. https://qt4cg.org/meeting/minutes/2022/12-13#approve-minutes
   8. https://qt4cg.org/meeting/minutes/2022/12-13#open-actions
   9. https://qt4cg.org/meeting/minutes/2022/12-13#technical-agenda
  10. https://qt4cg.org/meeting/minutes/2022/12-13#issue-281
  11. https://qt4cg.org/meeting/minutes/2022/12-13#pr-array-index-where
  12. https://qt4cg.org/meeting/minutes/2022/12-13#pr-parse-html
  13. https://qt4cg.org/meeting/minutes/2022/12-13#pr-fn-char
  14. https://qt4cg.org/meeting/minutes/2022/12-13#pr-type-diagrams
  15. https://qt4cg.org/meeting/minutes/2022/12-13#pr-xslt-function-override
  16. https://qt4cg.org/meeting/minutes/2022/12-13#pr-grammar-if-then-else
  17. https://qt4cg.org/meeting/minutes/2022/12-13#issue-170
  18. https://qt4cg.org/meeting/minutes/2022/12-13#issue-114
  19. https://qt4cg.org/meeting/minutes/2022/12-13#issue-107
  20. https://qt4cg.org/meeting/minutes/2022/12-13#any-other-business
  21. https://qt4cg.org/meeting/minutes/2022/12-13#adjourned
  22. https://qt4cg.org/meeting/agenda/2022/12-13.html
  23. https://qt4cg.org/meeting/agenda/2022/12-20.html
  24. https://qt4cg.org/meeting/minutes/2022/12-06.html
  25. https://github.com/qt4cg/qtspecs/issues/281#issuecomment-1336491005
  26. https://qt4cg.org/dashboard/#pr-258
  27. https://qt4cg.org/dashboard/#pr-259
  28. https://qt4cg.org/dashboard/#pr-261
  29. https://qt4cg.org/dashboard/#pr-268
  30. https://qt4cg.org/dashboard/#pr-279
  31. https://qt4cg.org/dashboard/#pr-284
  32. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0017.html
  33. https://github.com/qt4cg/qtspecs/issues/170
  34. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0017.html
  35. https://github.com/qt4cg/qtspecs/issues/114
  36. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0017.html
  37. https://github.com/qt4cg/qtspecs/issues/107

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 13 December 2022 17:42:43 UTC