QT4 CG Meeting 002 Minutes, 2022-09-13

* Minutes

Meeting: 002
Date: 13 September 2022
Chair: NW
Scribe: NW

** Summary of new and continuing actions [0/9]

+ [ ] QT4CG-002-01: NW to incorporate email feedback and produce new
  versions of the process documents.
+ [ ] QT4CG-002-02: RD to make a traige pass over the issues.
+ [ ] QT4CG-002-03: NW to setup the GitHub labels as discussed in email.
+ [ ] QT4CG-002-04: MK to add DN’s “op” function to the list.
+ [ ] QT4CG-002-05: EP to make links from the GitHub README files to
  the formatted specs.
+ [ ] QT4CG-002-06: DN to make a GitHub issue to track the question of
  whether we need array versions of all functions that take sequences.
+ [ ] QT4CG-002-07: MK to make a pull request incorporating the
  changes to fn:all.
+ [ ] QT4CG-002-08: NW to investigate automatically generating
  formatted specs from pull requests.
+ [ ] QT4CG-002-09: MK to make a pull request incorporating the
  changes to fn:some.

** Administrivia

*** Roll call [10/12]

+ [X] Anthony Bufort (AB)
+ [X] Reece Dunn (RD)
+ [ ] Christian Grün (CG)
+ [X] Joel Kalvesmaki (JK) [x:35-]
+ [X] Michael Kay (MK)
+ [X] John Lumley (JL)
+ [X] Dimitre Novatchev (DN)
+ [X] Ed Porter (EP)
+ [ ] Liam Quin (LQ)
+ [X] C. M. Sperberg-McQueen (CSM)
+ [X] Bethan Tovey-Walsh (BTW)
+ [X] Norm Tovey-Walsh (NW)

*** Agenda

Agenda: https://lists.w3.org/Archives/Public/public-xslt-40/2022Sep/0019.html

+ NW: I’d like to add a brief discussion about the labels.

Proposal: Accept the agenda as amended?

No objections.

*** Approve minutes of the previous meeting

Minutes of the previous meeting:  https://lists.w3.org/Archives/Public/public-xslt-40/2022Sep/0003.html

Proposal: Accept the minutes as posted.

No objections.

*** Appoint chair and scribe for meeting

+ NW volunteers, no objections.
  + Accepted

**** Process and plan

+ NW: We talked about the process-y documents a lot last week, and
  then in email. I’ll try to incorporate that feedback and see if
  we’re all happy with the results.
  + Does anyone want to talk about them more this week?

No one proposes to.

ACTION QT4CG-002-01: NW to incorporate email feedback and produce
                                               new versions of the process documents.

+ MK: We talked about process, but we didn’t talk a lot about plan.
  + … do we start breadth first, by doing a plan and a requirements
  document, or do we start depth first with some low hanging fruit
  before doing a more breadth first view.
+ JL: I agree with the implication that MK made last week that
  actually getting some purchase by doing a little bit would be good.
+ DN: In regards to ordering the items, it would be a good idea to
  make some kind of dependency graph. Don’t discuss things out of
  order.
+ NW: Are you volunterring?
+ DN: Maybe we should traige the lists first
+ MK: Noting dependcies is part of that triage process
+ NW: Volunteers?
+ RD: I’ll take a pass.

ACTION QT4CG-002-02: RD to make a traige pass over the issues.

Some discussion of labels and who can assign them.

+ DN: Because we’re looking for people to scan for dependencies, the
  person who made the proposal should also review the items they
  proposed.

+ NW: Good. We’ll review that in the future.

***** GitHub labels

+ NW: I thought what came out of the email discussion was really good.
  I suggest we adopt that for the time being, we can always change it
  as we go.

ACTION QT4CG-002-03: NW to setup the GitHub labels as discussed in email.

**** Appointment of permanent co-chairs and editor

+ NW: DN proposed that having a co-chair would look better. He
  suggested CSM and CSM has agreed.
+ CSM: I’m committing to co-chair for the next year, I plan to review
  my commitments in a year and see where we are.
  + … the CG should probably do that too!
+ NW: I agree

Proposal: CSM and NW to co-chair.

No objections.

**** Diversity

+ BT: Are we going to do anything to try to encourage diversity?
+ CSM: Is there anything we can do?
+ BT: We can work out what we can do if the CG is willing to make a
  commitment to try to encourage diversity.
+ DN: I don’t understand what’s being suggested.
+ BT: I think we should begin by making a commitment that we are
  willing to try to increase the diversity of the group. I think it’s
  hard to work out what we should do.
  + …If I weren’t married to one of this group, I wouldn’t be here
    because I wouldn’t feel fully comforable looking at this group. I
    wouldn’t feel like this is a place for me. I’m the only woman in
    this group and in the other CG I participate in.
+ NW: I think diversity would be good!

Proposal: The CG agrees that we should work to encourage diversity in
the group.

No objections.

+ AB: I’d like to thank Bethan for a really gutsy and straight-foward
presentation of the problem. I’m a newcomer and I feel somewhat
intimidated by these meetings. It’s hard to overcome my introversion.
I volunteer to join BT to figure out what we can do. I already have
some ideas.

+ NW: Thank you. And thank you for being here. 

** Technical Agenda

*** XPath 4.0 functions
  + See https://github.com/qt4cg/qtspecs/blob/master/editorial/functions-checklist.pdf

+ NW: What was your plan for this document, MK?

MK shares his screen to review the document.

+ MK: What I did was to start by listing the functions that either
  were either already in the draft spec from 18 months ago, or were in
  the issues list.
  + … It was a trawl through to find the functions that we have.
  + … The “usefulness” metric is more-or-less just gut feeling.
  + … Completeness is a little more objective
  + … Tests indicates where we have tests and some idea of completness

+ MK: My feeling is to start by taking that first list and see if we
  can approve them for incorporation in the spec.
+ DN: What about things that are missing?
+ MK: Let’s focus on what’s on the list first.

Some discussion of what the current state is. These functions are in
the specification but this group hasn’t adopted the specs as a baseline.

Some discussion of the missing function that DN was referring to.

ACTION QT4CG-002-04: MK to add DN’s “op” function to the list.

+ MK: I propose we go through them one at a time and see which ones we
  can approve.

Some discussion of where the specs are. The formatted specs are at
qt4cg.org, not directly in the repo.

ACTION QT4CG-002-05: EP to make links from the GitHub README files to
the formatted specs.

**** fn:all

+ MK: I think there should be two signatures.
+ RD: Doesn’t the second example need to be fn:boolean#1?
+ MK: Yes. Thank you.
+ MK: The same logic applies to the first one which I was struggling with.
+ CSM: Question: am I right to think this is extensionally equivalent to  every $i in input…
+ MK: That’s what the rule says (…points to the rule in the spec…).
  + CSM: I missed it. I propose that the rule should be a code block, not inline code!
+ CSM: This is just syntactic sugar for brevity?
+ MK: Not just for brevity. In a world of higher order functions, it
  becomes useful to have functionality encapsulated in a function. You
  can use this as an argument to array-filter, for example.
+ CSM: Now I’m puzzled by the signature returns xs:integer

Agreement that it should return xs:boolean.

+ DN: Maybe it would be good if there is a function like this for arrays.
+ MK: Yes, as a general issue, should we have array functions
  corresponding to every sequence function.
+ DN: I think it would be good so we don’t have to explain the distinction.

ACTION QT4CG-002-06: DN to make a GitHub issue to track the question
of whether we need array versions of all functions that take
sequences.

Some discusssion of what namespace these are in.

+ MK: I’ve used a bit of syntax in the examples that we haven’t
  approved yet. That might be a bad idea.
+ RD: I think it’s fine to keep it for now, if the syntax changes,
  we’ll have to fix the examples.

Proposal: add fn:all to the consensus draft?

No objections.

ACTION QT4CG-002-07: MK to make a pull request incorporating the
changes to fn:all.

ACTION QT4CG-002-08: NW to investigate automatically generating
formatted specs from pull requests.

**** fn:some

+ MK: This is very similar to fn:all

+ DN: Are we going to provide implementation hints?
+ MK: I think those are general rules.
  + We do often provide a sample implementation in XQuery or XSLT or both.
+ NW: Are we going to try to do that for all the functions, or only where it provides extra clarity?
+ MK: I think we’ve tended to do it where it adds clarity.
+ DN: I think this would contribute to the clarity.
+ CSM: If I understand correctly, DN is suggesting that we have code
  not to clarify the semantics of the function, which are given fairly
  explicilty by the rule, but to clarify that an implementation is
  allowed to short circuit the evaluation?
+ DN: No, those are two separate things.
+ JL: In both these examples, we have exactly that in the rule. You
  could write this yourself if you were allowed to write a function in
  the fn: namespace.
  + What is of interest to me is what happens if you have an error later on.
+ MK: Error handling is defined by general rules for XPath. We don’t
  like them, they’re horrible, but they exist!
+ DN: One more benefit is that it would ease testing. It can serve as
  an oracle for testing.
+ NW: Can we try it out and see what we think?

The scribe missed some description of what a potential implementation
might look like, for fn:all?

+ MK: The danger of providing a recursive implementation is that it
  would appear to invalidate a parallel implementation. It would have
  to be non-normative.
+ NW: Right, so the examples are sometimes more confusing.
+ CSM: I put this in chat:
    function($input, $predicate) as xs:boolean { every ... }
  anything beyond that?
+ DN: I don’t understand what you’ve written.
+ CSM: If you asked me for a sample implementation, I’d write what
  I’ve given above.
+ DN: Yes.
+ CSM: So the question in my mind is, is that all you wanted? I’d be
  happy with the rules as they are, but if the point of this is how to
  get from an expression to a function would work. In that case, it
  could be normative.
  + I take MK’s point, you don’t want to make the sample/reference
    implementation more specific than it should be.
+ DN: We just provide one implementation, we will not say that it is
  the normative implementations.
+ MK: The constraints on error behavior can also be different.
+ DN: In any case, I think it’s preferable to have it.
+ RD: I was going to say in this case where it’s trivial, I don’t
  think adding an implementation adds clarity. But it would make sense
  in more complicated.
+ NW: I think that comes back to my question earlier, it makes more
  sense when the functions are complicated. And DN is right, if the
  example implementation is too complicated that’s going to help us
  understand that maybe we’ve specified the function poorly.
+ MK: I’d forgotten that there are cases where we define it
  normatively. I have no objection to using the same style.
+ EP: Yes, we’re almost there in the rules. The spec is in the rule,
  we’d just have to wrap it in function and we’d be done.
+ AB: Doing it for examples where it’s complicated makes more sense to
  me than doing it all the time.
+ BT: There’s one argument for doing for everything where you think
  it’s very simple but the explanation makes you think maybe it’s more
  complicated.
+ MK: You can’t give example implementations for all functions.
+ NW: Let’s go with adding them when it adds clarity.
+ MK: I’ll try to use the spec style and we can

Proposal: add fn:some to the consensus draft?

No objections.

ACTION QT4CG-002-09: MK to make a pull request incorporating the
changes to fn:some.

** Any other business

Brief discussion of process and voting.

+ NW: With respect to voting, I’d rather not. My preferred style is to
  ask if there are any objections. If there aren’t any, we can move
  on. If there are, we have more discussion.
  + If we get to vote counting, you’ve really backed me into a corner!

** Adjourned

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica