QT4 CG Meeting 018 Minutes 2023-01-17

Regrets: BTW

• [ ] Anthony (Tony) Bufort (AB)
• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [ ] 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)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW). Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is scheduled for Tuesday, 24 January 2023.

No regrets heard.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
• [ ] QT4CG-015-02: NW to improve the width of the diagrams, perhaps multiple views
• [X] QT4CG-015-03: NW to make sure the direction of the arrow is in the legend See PR #308
• [ ] QT4CG-015-04: NW to investigate of a dynamic presentation is practical
• [ ] QT4CG-016-02: NW to add an ed-note indicating when it was approved.
• [ ] QT4CG-016-03: RD to add a note clarifying “known character encoding”
• [ ] QT4CG-016-04: RD to add a note clarifying the “*”/”*” html/version combination
• [ ] QT4CG-016-05: RD to add a “todo” noting the dependency on keyword arguments
• [ ] QT4CG-016-06: RD to reword the introduction to mapping to clarify who’s doing the mapping
• [ ] QT4CG-016-07: NW to make an issue about the problems of document-uri uniqueness
• [ ] QT4CG-016-08: RD to clarify how namespace comparisons are performed.
• [ ] QT4CG-016-09: RD to add a note stating that the local name should always be lowercase
• [ ] QT4CG-016-10: RD to consider how to clarify parsed entity parsing.
• [X] QT4CG-017-01: MK to clarify the characters numbers in points 1 and 2 of fn:char
• [X] QT4CG-017-02: MK to change the order of points to 3, 4, 1, 2 in fn:char
• [X] QT4CG-017-03: SF to follow up on whether or not the browser has all the Unicode and emoji names.
  • https://lists.w3.org/Archives/Public/public-xslt-40/2023Jan/0016.html
• [X] QT4CG-017-04: MK to revise PR #284 to include an optional else ‘else’

See pull request #284. Some discussion last week.

• MK thinks he had a clear action last week; has updated PR #284
• MK reviews #284
  • … MK reviews 4.15, Conditional Expressions
• MSM: I persuaded myself this wasn’t ambiguous because of the braces, but I’m worried about an if within an else that isn’t braced.
• RD: Do you mean a braced if with a regular if inside it?

Some attempt to construct an example on the fly…

At this point, some of the discussion is about examples presented in the chat window. The scribe does his best…

• MSM adds to chat:

  if (condition) { then-clause } else { else-clause }

  but in the case that the else-clause is a conditional, then

  if (condition) { then-clause } if (c2) { then-2 } else { else-clause }

• DN: If we substitute ExprSingle with another IfExpr and another unbraced action, then we’ll have else ambiguity.
• RD observes there’s a typo in the example

• MSM: Else ambiguity an only arise if you have conditions in the then clause. Let’s consider:

  if (condition) { then-clause } else if (c2) { then-2 } else { else-clause }

  if (condition) { then-clause } else { if (c2) { then-2 } else { else-clause } }

• MSM: What I was expecting to see required, but is only allowed, is that you can put the else clause in a braces.
• MSM: I was concerned about the first case but I think it’s unambiguous.
• MK: The special case of the intermede else-if clauses are only allowed a “then” branch, they aren’t allowed their own “else” branches.
• RD: One way to view this is that it’s kind of similar to switch and type-switch statements.
• MSM: I believe it is in fact unambigous.
• MK: It requires a single token lookahead but it’s unambiguous.
• RD: Another thing with respect to grammar ambiguity: this pattern is common in a lot of languages like C/C++/Java/C#/JavaScript/etc.
• MSM: Yes, but if you transcribe the grammar for C into clean grammar formalism, you will find that they’re full of ambiguities! They’re expecting manually written parsers. There are a lot of ad hoc rules and my life is not completely filled with regret that we didn’t hold the line on ad hoc rules better.
• RD: There are BNF grammars for C.
• MSM: Yes, and if you put them through a grammar analysis tool, you will find huge amounts of ambiguity. At least I did!

Some questions about the ambiguity of “C” arise. MSM agrees to dig up his notes.

The group seems satisfied that this is not ambiguous.

Proposal: Accept this PR.

Accepted.

• MK: What is the sentiment of the group about the ternary conditional?
• CG: Now that we have two alternatives for if/then, I could skip ternary expressions.

Some voices of agreement.

ACTION QT4CG-018-01: MK to make a PR that removes ternary expressions.

See pull request #304. This is Mike’s PR #292 redrafted by Norm. Mike writes:

I regret that this has turned into a bit of an omnibus PR. The main changes are:

• Fix validity issues with the function catalog and its schema (Issue 291)
• Convert all functions to use a single signature with optional parameters (Issue 70)
• Extend the function catalog to handle record definitions (Issue 257)
• Fix the (trivial) bug with properties of fn:path (Issue 288)
• Add introductory text concerning the handling of operators (Issue 35)

MK reviews PR #304.

• MK: The primary aim was to change the function signatures.
  • … For example, fn:string-join has one signature instead of two.
  • … There may need to be more ammendments to the prose if we find mentions of particular signatures.
• MK: I went on to address the title of the document in section 1.1 Operators.
• DN: Are all the functions from 3.1 that have more than one overload convert to this new format?
• MK: The vast majority are, but there are one or two that you can’t. For example, the single-argument form of fn:tokenize doesn’t have an equivalent form with default arguments.
• DN: If this is only partially done, we probably need an issue to review it.
• NW: The other thing you mentioned was fn:path
• MK: That’s a simple typo I fixed.
• JL: Are all the operators functionable now?
• MK: All the first-order operators are.
• MSM: In section 1.5 Function signatures and descriptions, strictly speaking it’s the local name of the function. The name of the function is “fn:”-function name.
• MK: In that paragraph, it should say fn:function-name

Some discussion of whether it would be better to use fn:function-name or to refer to the function-name as the local name.

ACTION QT4CG-018-02: MK to review “In this notation, function-name, in bold face…” in 1.5.

• MK: I raised some errata in the PR entry, but I propose to fix them after the merge.

ACTION QT4CG-018-03: MK to address the issues raised in the commeont on PR 304

• RD: I think I raise an issue for the “**” in the signature of fn:all-different, issue #62

Proposal: accept this PR

Accepted.

See pull request #290. This PR seems to be against an earlier draft so the diff markup is a bit odd. I believe the only intended change is the paragraph in 2.9.1 Functions.

• NW tries to explain his remark about 2.9.1
• MK: This change corrects the incorrect statement that there’s a hierarchy of function types. The rules for subtyping functions mean that the graph of subtypes of functions isn’t a heirarchy. It’s acyclic but not hierarchic.

Proposal: accept this PR

Accepted.

See pull request #286.

• MK reviews the PR
  • … This primarily effects XPath but also impacts XSLT.
  • … In 4.6.2.2 MK reviews the production changes
  • … The only other complication is where that fits into the grammar.
  • … There’s a change in 4.6.3 about reverse axes
• JL: Is the union required to be flat in the grammar? I can’t bracket inside the brackets?
• MK: Yes, that was a deliberate simplification.
• MSM: I found the explanation, “the predicate is not part of a step” a bit opaque. Would it be clearer to say that the predicate applies to the result of a union. That will remind some readers that unions sort into document order.

ACTION QT4CG-018-04: MK to consider the editorial suggestion on “a predicate is not part of a step”

• RD: Thinking about grammatical ambiguities, in addition to applying to forward and backwards steps it also applies to abbreviated steps.
• MK: Yes.
  • … Moves to 4.6.5 to show that you can’t have a union node test all on it’s own.
• MK: In XSLT…
  • … It’s all about how patterns and precedence interact with these changes.
  • … The default precedence is extended to cover this new case.
• MSM: Since the union node tests need to be flat, unlike a union expression, the union node test will always produce patterns with the same priority, no?
• MK: No, because…
• JL: Yes, because…

Some discussion ensues.

• MK: No, it can be a NameTest and a NameTest can have a wild card.
• MSM: Right. Thank you.

Proposal: accept this PR

Accepted.

We had some discussion of #281 previously, but no resolution. Awaiting more feedback from the CG in the issue.

• NW: Did you get more feedback?
• DN: Yes, there was a thread about additional guards. That got several informal approvals.
  • … We made progress in formalizing what lazy means.
  • … We can have lazy() as a function with a single argument.
  • … It’s body is another function with zero arguments and its body is the expression.
  • … If we a variable of type expression, then the result must not be inlined.
  • … Still waiting for some feedback from RD about laziness on a compound structure.
  • … RD proposed wildcard notation which means we don’t need other parts of the object.
• DN: I suggest we leave this open and give other people a chance to review.