QT4 CG Meeting 007 Minutes 2022-10-18

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.

Proposal: Accept the agenda.

Accepted.

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

None heard.

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

• [ ] 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 :-)

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

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 “$”)

• 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

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

• 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

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

• 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

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.