- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 11 Oct 2022 17:47:33 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2zge22tnn.fsf@saxonica.com>
Hello,
Here’s a link to the minutes.
https://qt4cg.org/meeting/minutes/2022/10-11.html
And for your convenience:
QT4 CG Meeting 006 Minutes 2022-10-11
Table of Contents
* Draft Minutes
* Summary of new and continuing actions [0/6]
* 1. Administrivia
* 1.1. Roll call [11/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/7]
* 1.6. Scheduling XSLT work
* 1.7. Timezones
* 2. Technical Agenda
* 2.1. Review pull request #197 (was 166; variadic functions)
* 2.2. Review pull request #198 (was 173; fn:op)
* 2.3. Review pull request #201 (was 188; editorial)
* 2.4. fn:while (previously fn:until)
* 2.5. HOF sequence functions and positional arguments
* 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-006-01: JK to review the variadic functions proposal in #197
* [ ] QT4CG-006-02: NW to make the changed files heading to be more
obviously a link.
* [ ] QT4CG-006-03: MK to make a separate proposal for supporting the
Unicode operator symbols
* [ ] QT4CG-006-04: NW to point to the dashboard links from the agendas.
1. Administrivia
1.1. Roll call [11/13]
* [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.
1.2. Accept the agenda
* NW: I’d like to discuss when the meeting time for this call is
anchored.
Proposal: Accept the agenda with NW ammendment.
Accepted.
1.3. Next meeting
The next meeting is scheduled for Tuesday, 18 October. Any regrets?
Regrets: EP.
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/7]
(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.
1.6. Scheduling XSLT work
* 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.
1.7. Timezones
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.
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.
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.
2.2. Review pull request #198 (was 173; fn:op)
* 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.
2.3. Review pull request #201 (was 188; editorial)
* 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.)
2.4. fn:while (previously fn:until)
* 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.
2.5. HOF sequence functions and positional arguments
* 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.
3. Any other business
* AB: What’s the process for starting a proposal and getting feedback
and discussion?
After brief discussion, consensus is that the best way is to create an
issue describing the problem that you’d like to solve. Can also send
email.
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 11 October 2022 16:48:46 UTC