QT4 CG Meeting 007 Draft Minutes 2022-10-18

The draft minutes are posted at

  https://qt4cg.org/meeting/minutes/2022/10-18.html

QT4 CG Meeting 007 Minutes 2022-10-18

Table of Contents

     * Draft Minutes
     * Summary of new and continuing actions [0/6]
     * 1. Administrivia
          * 1.1. Roll call [9/13]
          * 1.2. Accept the agenda
          * 1.3. Next meeting
          * 1.4. Approve minutes of the previous meeting
          * 1.5. Review of open action items [5/6]
     * 2. Technical Agenda
          * 2.1. Review pull request #197 (was 166; variadic functions)
          * 2.2. Issue #165, keyword arguments, “:=” or “:”
          * 2.3. Review pull request #199 (was 177; items before, etc.)
          * 2.4. Review pull request #200 (was 185; drop xsl:match
            instruction)
          * 2.5. Review pull request #202 (was 196; subtyping)
          * 2.6. Review pull request #203: Issue 151: map:build
          * 2.7. Review pull request #206: Corrections to math:atan2
          * 2.8. Issue #170, XPath “otherwise” operator
     * 3. Any other business

Draft Minutes

Summary of new and continuing actions [0/6]

     * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
       diversity in the group
     * [ ] QT4CG-005-03: RD to review the variadic functions proposal in #197
       (formerly #166)
     * [ ] QT4CG-008-01: MK to implement the resolution of issue #165 (“:=”
       and no “$”)
     * [ ] QT4CG-008-02: NW to fix or replace #199, it doesn’t reflect the
       original correctly
     * [ ] QT4CG-008-03: NW to make the GitHub PR link to the diffs
     * [ ] QT4CG-008-04: RD to review pull request #202
     * [ ] QT4CG-008-05: NW to make an issue for Martin’s proposed ammendment
       to map:build

1. Administrivia

  1.1. Roll call [9/13]

   Regrets: BTW, EP

     * [X] Anthony Bufort (AB)
     * [X] Reece Dunn (RD)
     * [X] Christian Grün (CG)
     * [X] Joel Kalvesmaki (JK)
     * [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). Chair. Scribe.

  1.2. Accept the agenda

   Proposal: Accept the agenda.

   Accepted.

  1.3. Next meeting

   The next meeting is scheduled for Tuesday, 25 October. Any regrets?

   None heard.

  1.4. Approve minutes of the previous meeting

   Proposal: Accept the minutes of the previous meeting.

   Accepted.

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

   (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
          * Continued
     * [X] QT4CG-005-03: RD to review the variadic functions proposal in #197
       (formerly #166)
     * [X] QT4CG-006-01: JK to review the variadic functions proposal in #197
     * [X] QT4CG-006-02: NW to make the changed files heading to be more
       obviously a link.
          * Changes commited to the gh-pages branch on 11 October 2022
     * [X] QT4CG-006-03: MK to make a separate proposal for supporting the
       Unicode operator symbols
          * https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0037.html
          * https://github.com/qt4cg/qtspecs/issues/204
     * [X] QT4CG-006-04: NW to point to the dashboard links from the agendas.
          * See this agenda, for example :-)

2. Technical Agenda

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

     * See pull request #197 (you’ll find links to formatted versions of the
       specs at https://qt4cg.org/).
     * See also the nexus of issues #162, #161, #160, #159, #158, #157, and
       #155.
     * See the discussion from last week.

   Mike summarizes the reviews so far.

     * MK: There are difficulties with the presentation, many of which derive
       from the 3.1 spec. I haven’t seen any comments related to the
       technical questions.
     * RD: JK asked about “=” or “:=”.
     * MK: Yes, we have a separate issue for that.
     * MSM: I would like to pose a question, but it will lead to bike
       shedding.
     * NW: You have 5 minutes.
     * MSM: When I was reading it, I became less and less comfortable with
       the term “declared function” because we have to explain several times
       that it isn’t a function, it’s a function family.
     * MK: Yes, I’m proposing to change that to “function definition.”
     * MSM: I thought “function family” might be a possibility.
     * MK: I tried that. I think it sounds too much like a set of functions,
       which it isn’t really because there’s also additional metadtaa, so I
       decided not to use that.
     * MSM: If we allow implementations to search multiple namespaces and
       resolve conflicts, is it somehow inconsistent?
     * MK: It’s unfortuante that tht issue has raised its head here. The
       reason is that in my first draft, I proposed changes to function
       resolution, partly to make more legitimate what XSLT was doing with
       overrides and packages. Some of the chagnes aren’t a substantive part
       of the proposal, they’re designed to tidy up text that should never
       have been there.
     * MSM: But if we allow host langeauges to supply conflict resolution
       rules for some kinds of conflicts, forbidding it from resolving arity
       conflicts seems odd.
     * MK: Yes, there’s a bit of a tension there because XSLT has always has
       its own rules. Those have never been reflected in XPath which is why I
       tried to generalize the text.

   We’ll come back to this again next week.

  2.2. Issue #165, keyword arguments, “:=” or “:”

   MK proposes that this issue may be ready to be decided.

     * MK: The initial issue was what symbol do we use and then it was
       widened to the question of whether we should put a $ in front of the
       keyword.
     * RD: Doesn’t that conflict with scripting extensions?
     * MK: We already have conflicts there, so that doesn’t help me.
     * DN: I would prefer not to use $ because it is more typing and I have
       ides for using $ or $$ for something else in the future.
     * RD: If we use $ in the function call, doesn’t that mean that we then
       have a parsing ambiguity that breaks the current convention of having
       a two symbol look-ahead to resolve conflicts? Having an NCName
       followed by a colon would be a keyword parameter whereas $NCname could
       be a parameter being passed to a function call or it could be defining
       a name parameter.
     * MK: I think there are already places where we need two character
       look-ahead.
     * RD: But what about more than two?

   Some discussion about whether “$” “NCName” “:” is two or three symbol
   look-ahead.

     * CG: I would vote against $, because I think variable references and
       declarations would look pretty similar. In NW’s example, there’s a let
       keyword in front. One of my proposals was to use a simple string
       followed by a colon.
     * NW: Is that a third propsal, “:” instead of “:=” or “=”
     * CG: Yes.
     * MK: I think putting it in quotes has too much of an implication that
       you can define the name variably instead of literally.
     * RD: If we extend this to support map keys, if we don’t allow strings,
       don’t we have the restriction that we can’t reference keys with
       spaces? So we’d need to support stings. If we only support strings, we
       don’t allow QNames. Whereas parameters can be QNames. We need to
       support EQNames and if we extend it to map keys, strings.
     * MK: I think there are two questions, := or : and the use of $. I think
       the impression I got is that the discussion favored := because it’s
       similar to other places where we bind values to parameter names, like
       declaring the default in an XQuery function declaration and it reduces
       some for ambiguity when you have a QName there.

   Proposal: use “:=”

   Accepted.

     * NW: Do we want to resolve the $ question now?
     * MK: It would be nice to resolve it, I think we know everything we need
       to know. It’s technically redundant, we’re only doing it because we
       use them everywhere else. It draws it out visually. I’m marginally in
       favor of including it, but it’s not something I feel immensely
       strongly about.
     * MSM: I agree
     * RD: I’d be against it because it would be a conflict with the
       scripting extension syntax.
     * DN: From what I hear, I have a feeling the majority is opposed to the
       $. I’d like to add one more thing, it’s because $name can very easily
       be construed as a reference to a variable and we could even have $x :=
       $x.
     * AB: I’ll register my agreement with RD not to do it.

   Proposal: No “$”

   Accepted.

   ACTION QT4CG-008-01: MK to implement the resolution of issue #165 (“:=”
   and no “$”)

  2.3. Review pull request #199 (was 177; items before, etc.)

     * See pull request #199
     * MSM: My comment on it came just before the meeting.

   In the course of attempting to review the item, we discovered that the PR
   is malformed.

   ACTION QT4CG-008-02: NW to fix or replace #199, it doesn’t reflect the
   original correctly

  2.4. Review pull request #200 (was 185; drop xsl:match instruction)

     * See pull request #200
     * MK: I proposed it a while ago. The intent was to find a way to use
       pattern smore flexibly, but I haven’t really found a proposal that I’m
       comfortable with. I’m not happy, so I prefer to drop it.

   Proposal: Accept PR #200, drop xsl:match

   Accepted.

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

     * See pull request #202
     * MK: This is essentially an editorial proosal, though it does fill a
       few gaps in the subtyping rules. It’s designed to use a more generous
       layout for the rules and a more readable notation. It’s easy to find
       the rules you want and the more generous layout offers more room for
       examples.
     * JL: I have a question on procedure. I’m trying to find out where the
       information is.

   Some discsion of the difficulty in finding the item. The organization of
   the qt4cg.org pages, and the relationship to the GitHub pull request is
   not as clear as it could be.

   ACTION: QT4CG-008-03: NW to make the GitHub PR link to the diffs

     * RD: I’d like to review the proposal.

   ACTION: QT4CG-008-04: RD to review pull request #202

  2.6. Review pull request #203: Issue 151: map:build

     * See pull request #203

   MK walks us through the proposal.

     * MK: Martin Honnen also raised discussed this in email.
     * MK: This was previously described as map:group-by() that was less
       powerful.
          * They way you do this today is with map:merge() which is
            unintuitive and clumsy.
          * The modification that Marin has proposed is that you should be
            able to compute more than one key for each item in the input
            sequence, all of which will be bound to the same value
          * That conflicts with the way thtat DN might like to extend it, by
            allowing keys to contain multiple atomic values. That would, say,
            generate one composite key rather than multiple single keys.
          * I’m fairly neutral to Martin’s extension; I’d be happy to accept
            it but I don’t care strongly.
     * MSM: DN, can you clarify something? I can see the utilty of having the
       same item reachable thorugh mutliple keys. I can’t describe a use case
       off the top of my head, but Martin’s proposal feels intuitive to me.
       When I have a compound key, or something that would in other contexts
       be called a compound key, I tend to use nested maps. I haven’t felt
       any more unhappy with that than I am with maps generally. I’m
       wondering, what do we get from allowing a sequence serve as a key?
     * DN: There is a separate issue in which this is discussed quite
       throughly (scribe believes it is #119). There, I also have an example
       with nested maps and as an alternative. But it feels like it is quite
       challenging, even for two nested maps. It would practically be
       impossible for even deeper maps
     * MSM: Ok, I’ll look at that issue.

   NW asks if we could resolve this issue independently of Martin’s
   suggestion. Agreement is we could.

   ACTION QT4CG-008-05: NW to make an issue for Martin’s proposed ammendment
   to map:build

     * DN: Because we just provide the input, I undestand that we can
       construct the key and the map is a function from the key to the value.
       But the way I first read it, was that the value is a function of the
       input, not the key. Maybe the prose could be clarified?
     * MK: I’ll see if I can construct an example that demonstrates that.
     * JL: This gives me a mapping that’s normally an identity and we can do
       a replacement in parts of that.
     * MSM: I’ve struggled a bit with map:merge, partly because of an
       implementation detail, but my recolleciton is that in map merge,
       there’s a kewyord for what to do with duplicates and here it’s a
       function.
     * MK: The five options we provide on map:merge can all be implemented by
       very simple funtions. And there are lots of other options that you
       might want, that you could also do with functions. Providing a general
       function instead of a selection of four would be a useful enhancement.
     * MSM: Thank you.

   Proposal: Accept pull request #203.

   Accepted.

  2.7. Review pull request #206: Corrections to math:atan2

     * See pull request #206
     * RD: I noticed when looking at the way math:atan2 was specified was
       that it didn’t match the output that it should. So I in my issue I
       outlined the issues and MK has fixed them.

   Some discussion of the IEEE spec.

   Proposal: Accept pull request #206.

   Accepted

  2.8. Issue #170, XPath “otherwise” operator

   MK proposes that this issue may be ready to be decided.

   There’s no PR for this issue because the text is already in the draft.

     * MSM: If I’m understanding this correctly, in cases where the left hand
       argument returns at most one item, this has the same effect as
       ($a,$b)[1]. This generalizes that to allowing either operator to
       return multiple items.
     * MK: Yes. It has two benefits. One is, the existing notation ($a,$b)[1]
       is highly obsecure. And the other is that it enables you to let the
       left hand operand be a multi-item sequence.
     * DN: I think everything is clear, but from my practice as a developer.
       I think there could be a confusion. What’s proposed is that if the
       left hand side (LHS) is the empty sequence, we choose the right hand
       side (RHS). Some peple may think this is applicable if the LHS is the
       empty string or false(), can we do something about this?
     * JK: In that spirit, I’d like to propose a synonym, fallback which may
       avoid the confusion.
     * RD: I’d be wary of extending it to things like false() or the empty
       string. It could led to confusing behavior like in JavaScript.
     * MSM: To put it on the table, we could do two things to address the
       concern: one is to revise the proposal in the direction of saying if
       the effective boolean value (EBV) of the LHS is false then take the
       RHS. The alternative is use a different keyword to avoid the mental
       association with booleans.
     * RD: If you have something like $x := false() return $x otherwise 2,
       then you would expect it to return $x but if we allow EBV, then it
       would return false(). What this is solving is the case where you have
       the empty sequence!
     * DN: From C#, there is a function is-null-or-empty and another other is
       is-null-or-whitespace. There’s an operator that does null as well.
     * JL: I’d favor keeping the current propsoal because what you’re tryign
       to do is make it clear what the current practice of using ($a,$b)[1]
       is for!

   Time is up. We’ll have to come back to this next week.

3. Any other business

   None heard.


                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 18 October 2022 17:06:30 UTC