QT4 CG Meeting 009 Minutes 2022-11-01

Regrets: BTW

• [ ] Anthony (Tony) 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)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW). Chair. Scribe.

Proposal: Accept the agenda.

Accepted.

The next meeting is scheduled for Tuesday, 8 November. This conflicts with Declarative Amsterdam.

Shall we meet?

After some discussion, yes, next week will be chaired by MSM and will focus on XSLT issues.

ACTION: QT4CG-009-01: NW to coordinate with MK on an agenda for next week.

Regrets for 8 November: NW, JL, CG.

Proposal: Accept the minutes of the previous meeting.

Accepted.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
• [X] QT4CG-005-03: RD to review the variadic functions proposal in #197 (formerly #166)
• [ ] QT4CG-007-05: NW to make an issue for Martin’s proposed ammendment to map:build
• [X] QT4CG-008-01: MK to review RD’s comments on PR #202
• [X] QT4CG-008-02: NW to review MKs comments on PR #215
  • Updates to PR #215
• [X] QT4CG-008-03: MK to make a PR for issue #96, starts|ends-with-sequence
  • PR #222

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 three weeks ago, two weeks ago, and last week.

We hope to resolve this PR this week.

• MK: I believe I responded to all the comments. None were particularly problematic. Just minor mistakes. One technical issue that is now an error condition.
• RD: I made a few comments about an hour ago.
  • RD walks us through his comments on the pull request

It appears that MK’s most recent commits haven’t been reflected in the diffs.

ACTION: QT4CG-009-02: NW to work with MK to make sure PR #197 is updated correctly

We’ll revisit this in two weeks.

See pull request #202

• MK: No progress, I haven’t responded to the latest comments.

See pull request #210

• CG: The latest issue was how to name the function. If the function is named fn:while then we can’t introduce a while keyword later because it will create a conflict. MK proposed fn:iterate. We could also use fn:until with the semantics reversed.
• NW: I like the similarity of fn:iterate with XSLT.
• MSM: Is that a conflict with XSLT?
• NW: No, because it’s an instruction in XSLT, not a function.
• MK: The semantics have enough of an analogy that it seems reasonable.
• JK: Is there a way to setup the keyword while so that there’s some sytax after it that prevents any confusion?

Some discussion of whether or not we could distingish the keyword from the function.

• MSM: Depending on exactly what people have in mind for a while keyword, my gut feeling is that I expect a while to be followed by a boolean expression. So we can’t solve the lookahead problem that way.
• RD: The only problem using while which would confuse it with a keyword would be in the case where while would have a parenthesis following it because that applies to keywords like typeswitch, if, and others. Given that the while expression is following the FLOWR syntax, I don’t see it raising a clash in the grammar.
• MK: There would be a conflict if you allowed it as the first thing in an expression and allowed it to be followed by an expresison.
• CG: Do we think in the future we may get rid of the for and let as the beginning of the FLOWR clause?
• MK: I think this is a question of trying to avoid restricting our options downstream.
• MSM: CG, was your alternative name until or repeat?
• CG: It was until but it could be repeat.
• MK: I quite like repeat.
• MSM: For those of us with Pascal backgrounds, repeat differs from while in that the loop is bound to occur once.
• CG: If you inverted the condition, it would always execute at least once. I like while because it’s more popular and you don’t have to have a negated condition.
• DN: Comparing while and until, I don’t think they’re the same at all.
• MSM: I think I could live with any (almost any?) of the proposed names, but in the end if we don't want to use while, I think I lean towards iterate for the parallel to xsl:iterate
• DN: There is also a proposal for a while keyword. What’s the difference?
• CG: I think the main difference is that if you have a FLOWR epxression you’re operating on a sequence . With the while function you can have arbitrary inputs that are transformed by the body.
• MK: In that respect, it is quite different from xsl:iterate as that does operate over a sequence.
• NW: Mmm, true.
• MSM: That pushes me back to repeat or until if we can’t use while. That difference that CG has just identifeid is significant.

Leave it for a week?

• MK: One approach is to adopt a name that we don’t like and then after you’ve used it for a while, and you can revisit the name later.
• RD: Would it make sense to keep while for now in that case?
• DN: Can someone write some comments on the issue? I feel very confused right now.

Let’s come back to this in two weeks.

Let’s all try to follow up in the issue so that in two weeks we’re ready to pick a name, or pick a name we don’t exactly like to live with for a while. In either case, pick a name!

See pull request #215

NW walks through the current prose for parse-uri.

• JL: Does reconstructing give back the original or an equivalent?
• NW: That’s a little hard to answer before I redraft the build function.
• MK: How well does this play with resolve-uri?

Some discussion. MK observes that if resolve-uri has stricter semantics, you could end up deciding you had a relative path but then it would be rejected by resolve-uri. That’s a mess.

ACTION: QT4CG-009-03: NW to investigate the relationship between PR #215 and resolve-uri.

• MSM: Two questions and a comment. you said in introducing the function you had started by thinking we could parse against RFC 3986 and shifted to something else to deal with relative URIs. But RFC 3986 has two roots, wouldn’t that be sufficient.

ACTION: QT4CG-009-04: NW to review RFC 3896 wrt relative URIs

MSM highlights the rule about matching a drive letter that NW had missed in his description.

• MSM: This rule and the backslash rule will be lossy. So to JL’s question, you’ll get a functionally equivalent URI.
• RD: Three points. First, the return type is map where the value is string, but some of the components return an array of strings. Second, wouldn’t this be better specified as a record type? Third, Do we want to reference what the WHAT WG URL document?

ACTION: QT4CG-009-05: NW to fix the return type for parse-uri; consider using a record type.

• DN: This question is more of a wish: I’d prefer if the test cases included tests for the error conditions.
• NW: Yes, of course, that’s an oversight.

ACTION: QT4CG-009-06: NW to add error tests for parse-uri.

• CG: Instead of returning an array of strings, what about returning a map of the query segments?
• NW: That’s tricky because the keys aren’t necessarily unique, it would have to be an array of maps.
• MK: We’re considering improvements to the lookup operator that would work on an array of maps.
• NW: Right then, that’s enough to make me think that’s better.

ACTION: QT4CG-009-06: NW to make the query segments an array of maps.

See pull request #222 and issues #94 and #96.

• MK: I’ve propopsed three new functions. The main thing I discovered is that these are far more poweful than I realized in that the matching doesn’t have to be an equality match. You can look for a sequence of paragraphs by matching on the name of the child element, for example.

Proposal: Accept this PR.

Accepted.