QT4 CG Meeting 006 Minutes 2022-10-11

• [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)
• [X] Ed Porter (EP)
• [ ] Liam Quin (LQ)
• [ ] Adam Retter
• [X] C. M. Sperberg-McQueen (MSM)
• [X] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW). Chair. Scribe.

• NW: I’d like to discuss when the meeting time for this call is anchored.

Proposal: Accept the agenda with NW ammendment.

Accepted.

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

Regrets: EP.

Proposal: Accept the minutes of the previous meeting.

Accepted.

(Items marked [X] are believed to have been closed via email before this agenda was posted.)

• [X] QT4CG-002-01: NW to incorporate email feedback and produce new versions of the process documents.
  • https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0027.html
• [X] QT4CG-003-03: NW to tweak the CSS for function signatures to avoid line breaks on - characters.
  • https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0012.html
• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
  • Continued
• [X] QT4CG-005-01: NW to update the W3C CG page to reflect the current chairs
  • https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0001.html
• [X] QT4CG-005-02: NW to investigate how the function dropdown works and if it’s buggy
  • https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0002.html
• [ ] QT4CG-005-03: RD to review the variadic functions proposal in #166
  • Continued
• [X] QT4CG-005-04: MK to draft a concrete proposal for the range-related functions
  • See pull request #177, also below.

• MK writes:

I'd also like to talk about how we tackle XSLT issues - would anyone prefer if some meetings were dedicated to that spec?

• MK: Should we do 1 meeting a month on XSLT? Or shall we mix it in?
• JL: I’d like to see some work on the XSLT side.
• NW: I’ll mix them in if we don’t have special meetings
• MSM: Will there be analagous XQuery issues? If so, we can designate some meetings for XQuery.
• DN: XSLT and XQuery depend on XPath, so we should be aware of that and discuss XSLT and XQuery with XPath.
• RD: I think it’s useful to discuss XSLT and XQuery together.
• CG: I think we have lots of XSLT issues that need to be discussed, regarding XQuery most things are XPath specific but we may have XQuery things in the future.
• lRD: I think some of the annotations work may be XQuery-specific.

Proposal: We’ll mix the XSLT and XQuery issues into the regular meetings.

Accepted.

After discussion, the proposal is that we will stay on European time.

Accepted.

DN observes that the meeting of 1 November is the only one when the relative meeting time will be out-of-sync due to varying changes to standard time.

The proposal to skip meeting on 1 November did not get traction.

• 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.

MK asks if the CG would like him to walk through the proposal. General agreement, “yes”.

• MK scrolls through the XQuery spec:
  • …reversion of default function namespace to what it was before
  • …changed statically known functions to “declared functions”; they aren’t just functions
    • There’s a model for functions and the fact that they now have optional parameters
  • …Lots of irrelevant changes because production numbers changed
  • …Statically declared functions has been changed. Rules for matching by name and arity.
  • …Syntax for static function calls; we use := for the separator.
    • There’s a separate issue for whether a $ is required before arguments; draft doesn’t include it.
  • …Changes to function calls; a declared function can now have an arity range
    • Arity ranges must be non-overlapping
  • …Positional arguments are bound first, then positional ones, then defaults
  • …Evaluate all the expressions, including the defaults, in the dynamic context of the function call.
  • …Then you do type conversion using coercion rules
  • …Dynamic function calls don’t change all that much, only positional binding is allowed in the current proposal.
  • …Named function references are again based on binding the arity
  • …Function declarations now declare a “family” of functions.
  • …More detail is spelled out here, it probably should have been in the previous spec too.
• MK: Essentially same the rules exist in the XSLT spec, but I won’t go through it.
• JL: I seem to have missed where the arbitrary number of arguments (i.e. concat()) is handled.
• MK: That’s not in this proposal, it’ll come later. Concat is still handled here as a completely special case.
• DN: I think it says that in a function call the expressions for the arguments are evaluated and then the function is called.
• MK: Yes.
• DN: Is there any reason why the arguments should be evaluated eagerly? I’m going to submit a proposal for lazy evaluation.
• MK: Section 2 of the spec gives you license to evaluate them lazily or not at all.
• DN: Exactly, because some functions are useless without lazy evaluation. I think we as a group should look into this.
• MK: By all means submit a proposal, but be aware that the problems historically in the errors and optimization sections have been profound. The error handling is weakly and informally described. How much optimization you’re allowed to do is a troublesome area.
• RD: You also have to be careful with things like the context item. You must make sure that you’re lazily evaluating it in the dynamic context in which it was called, not the context in which the parameter name is referenced.
• MK: Getting all that right is quite challenging in terms of getting language that’s formal enough to get interoperability.
  • …We always balked at trying to do a formal model for error handling. It’s a weakness in the language.
• MSM: If I understand correctly, you’ve chosen the approach that in the data model we have functions and the functions in the data model have invariably a fixed arity. A declaration that declares optional arguments declares a family of functions. It seems to me, as you were going through, that if I bind a variable to I’ll say “a function” but I’m using the term informally, what I get may depend on how I do it. If I want to bind my variable $v to f by anme, then I’ll say $v := f#2. If I say $v := someExpression(with,params) then I seem to have $v bound to the set of members in that family?
• MK: Inline functions haven’t changed.
• RD: We have a separate issue to investigate whether or not we can do that.
• MSM: So here the shoe pinches because the function item doesn’t have quite the same form as the declaration.
• RD: Named function item reference is always bound to a specific arity.
• MK: And a partial application gives you a fixed arity function where some arguments are bound and some aren’t.
• RD: That’s using the ? notation?
• MK: Right.

Some discussion of whether we can assign reviewers for pull requests as DN suggests. We encourage volunteers, but it’s not clear to the chair that we can usefully assign readers.

• JK: What’s the method for reviewers to give feedback?
• NW: I think that comments on the pull request are a good idea. Start an email thread if you think that will be more productive.

RD describes the GitHub approval process.

• JK: I’ll review #197.

ACTION QT4CG-006-01: JK to review the variadic functions proposal in #197

• MK: It would be nice to somehow know what specs have changed.
• NW: The “changed files” link on the dashboard is meant to be an aid, I’d like to do better.

Ed suggests making the changed files link underlined and make the cursor.

ACTION QT4CG-006-02: NW to make the changed files heading to be more obviously a link.

• NW: We’ll come back to this again next week.

• See pull request #198
• CG: I had a quick look and I think it’s fine.
• MK walks us through it:
  • … It adds an fn:op() function…
  • … Defined in terms of a lexical expansion
• JL: Is this intended also to handle the Unicode symbols for the various operators?
• MK: I’d forgotten those! I guess if we go ahead, they should be added.
• RD: They should also be added into the grammar as well.

ACTION QT4CG-006-03: MK to make a separate proposal for supporting the Unicode operator symbols

Proposal: Accept PR #198

Accepted.

Some discussion of whether or not the “history” section will continue to exist when we publish the specification. Opinion is divided.

• JK: It would help readers if there was a link to where the binary operators are defined.
• NW: That’s a good idea.
• MSM: I’d like a link to the entry for the pull request on the dashboard.

ACTION QT4CG-006-04: NW to point to the dashboard links from the agendas.

• See pull request #201

RD observes that this pull request has a couple of approvals and seems straightforward…

• NW: Good point.

Proposal: Accept this PR #201

Accepted.

(Chair skips several items as time is short, moves to the items CG requested.)

• See #80

CG suggested that this might complement the discussion of splitting sequences, see #149.

• CG: Thanks for all the discussion.
• CG shares his proposal in issue #80
  • … Discussion of recursive algorithms and why “while” might be easier to understand
  • … I think there are no equivalent solutions right now
• MK: Other than recursion.
• MK: My feeling is a bit like my reaction to “fold”, I’ve never seen myself needing this. But over the years, you come to grow and love fold, as you discover it’s power.
• RD: There are cases, especially adapting algorithms from imperative languages where you need to keep track of a loop variable that is difficult to do in XQuery. One example is parsing CSV where you need to keep track of where your splitting.
• NW: I’m in favor of things that make recursion less necessary.
• JL: I concur with MK’s point.

Consensus is that CG should write up a proposal.

• See #181

CG says “I haven’t drafted a full proposal yet, as I’d first like to hear what everyone thinks about it.”

After brief discussion, general agreement that CG should go ahead and draft a proposal.

• DN: I was the under the impression that indpendently from this function, MK submitted a langauge propsal about while, so maybe we need to know how they’re related.
• MK: I think when we have two proposals with overlapping functionality, we can take a look and decide which to accept.