QT4 CG Meeting 011 Minutes 2022-11-15

Regrets BTW

• [X] Anthony (Tony) Bufort (AB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [0:15-]
• [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.

The next meeting is scheduled for Tuesday, 22 November.

Regrets: JL for 22 and 29 November.

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
• [X] QT4CG-007-05: NW to make an issue for Martin’s proposed ammendment to map:build
  • See issue #236.
• [X] QT4CG-008-04: MK to submit a PR for fn:parseQName() to resolve PR #207
  • Mike reports the action is complete in PR #207
• [X] QT4CG-009-01: NW to coordinate with MK on an agenda for 8 November.
• [X] QT4CG-009-02: NW to work with MK to make sure PR #197 is updated correctly
• [X] NW to update PR #215
  • [X] QT4CG-009-03: NW to investigate the relationship between PR #215 and resolve-uri.
  • [X] QT4CG-009-04: NW to review RFC 3896 wrt relative URIs
  • [X] QT4CG-009-05: NW to fix the return type for parse-uri; consider using a record type.
  • [X] QT4CG-009-06: NW to add error tests for parse-uri.
  • [X] QT4CG-009-07: NW to make the query segments an array of maps.
• [X] QT4CG-010-01: DN to create an issue for proposing an optional else in XPath/XQuery
• [X] QT4CG-010-02: MK to incorporate the suggestions made by MSM on @then/@else on xsl:if
  • https://lists.w3.org/Archives/Public/public-xslt-40/2022Nov/0013.html

We’ve been keeping PRs open while detailed comments are worked out. I think that’s a fine model, but it has the consequence that we end up with a lot of PRs open for a long time. That increases the chances that we’ll create merge conflicts, making our life more difficult later, and means that there are many slightly different copies of each spec to review.

I propose that we agree to merge PRs as soon as the group feels that the proposal is complete enough to accept in principle. We can add a note in the history (for functions, at least) that it’s provisionally accepted until detailed comments are resolved, or words to that effect.

In the very short term, I would especially like to merge all of the PRs that are open against F&O so that the XML validity errors and the new markup for “type references” can be sorted out.

• RD: That makes sense
• JL: Where do discussions happen?
• NW: I think we get discussion in the issues until there’s a PR, then on the PR.
• MSM: In groups that I have been in that use a two-pass approach, the point of not considering things changed until the wording is all correct, one side effect is that if there are minor side effects in the wording, if we merge earlier, is there a way to ensure that nits don’t fall under the table?
• MK: I’ve usually seen that managed through actions
• MSM: Okay.
• NW: At least in F&O, we have a history section where we can observe that it’s unresolved.
• MK: XMLSpec also has an ednote; we could render them.

ACTION QT4CG-011-06: NW to make sure ednotes are rendered.

Proposal: merge PRs when they’re accepted in principle.

Agreed.

DN observes that he had trouble getting into the meeting. There was a different Zoom link and passcode last week and, for some reason, Zoom asked DN for a passcode this week.

ACTION QT4CG-011-07: NW to make sure the meeting passcode is on the logistics page

• 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 meeting 006, meeting 007, and meeting 008.

NW updated the PR with MK’s most recent changes.

We hope to resolve this PR this week.

• MSM: I noticed that somewhere in the middle, some of the new text uses the unqualified term “function” and it caught my eye partly because early on in this pull requestion there’s a note that we use the term “function item”. Was that change intentional, or does it need a tweak?
• MK: This crosses a couple of PRs. The Data Model uses the term “function” to mean an item. I’ve for the moment stuck to that, but I’ve also proposed changing it otherwise it gets too confused with static functions which aren’t function items.
• MSM: I had the impression that in a lot of cases in this PR we were using function item.
• MK: Yes, but it’s probably not uniformly applied.
• MSM: I’m pretty sure that the bit that caught my eye was “apropos of lookup” where there’s a reference that’s neither to a function definition or a function item, just a “function”.

Subsequent discussion reveals that the editor thinks the sentence is (too?) informal.

ACTION QT4CG-011-01: MK to fix the reference to “function” in XPath 4.4.1.

• RD: Looking through the grammar, the function signature with defaults is a sequence of param with defaults with optional default values. So according the grammar you can interleave optional and non-optional parameters. But elsewhere we say that required ones have to come first.
• MK: I decided to make that an extra-grammatical rule.
• RD: That makes sense, the grammar is difficult to get right.
• NW: An action to add it to A.1.2?
• MK: No, I don’t think that’s necessary. We have too many constraints like this that aren’t mentioned.

Proposal: Accept this PR?

Accepted.

• See pull request #210 and the minutes of two weeks ago.

We hope to resolve this PR this week.

• CG: I renamed the function from fn:while to fn:iterate-while per DN. Most use cases can be realized with this function, so I haven’t explored the until variant.
• MSM: The one question I have relates to a remark that MK made. If you want to generate a sequence of items until something happens, is there a way to do that using fn:iterate-while. This isn’t a reason not to accept the proposal, I’m just curious.
• CG: I think it’s absolutely possible, you can generate any kind of data structure you want. You can pass the sequence along, etc.

Proposal: Accept this PR?

• DN: I think that it would be good to discuss fn:iterate-until now.
• MK: Do we have a spec for fn:iterate-until?
• MSM: How would it be different?
• DN: The condition is just the opposite condition.
• CG: We also talked about having the action performed at least once. Then we wouldn’t need to negate the predicate.
• MK: Point of order: there’s no proposal for this.

ACTION QT4CG-011-02: CG to work with DN to propose an “until” variant.

Proposal: Accept this PR?

Accepted.

See pull request #202

• MK: The principle changes are to the section on defining subtyping rules. There were two major comments on the original proposal: lots of good detail from RD and a question of the fundamental nature of atomic values from MSM. I propose to address the latter in a different issue.
  • … This primarily addresses the subtyping rules that are common between XPath and XQuery.
• NW: The diffs are awful, they don’t deal with the notation changes.
• MK: Where RD raised technical questions, I’ve managed to persuade myself that it’s only more explicit.
• RD: I’m happy with the changes. The only minor thing is that in the generated output, the example blocks don’t have the proper styling.
• MSM: An editorial point, hopefully not a bike-shedding issue, you are using the notation “itemtype-subtype” with two arguments as a more verbose way of notating the subtype relation. But my instinct is that if you are going to name a binary relation for the types or roles of its arguments, the order of the name should be the same as the name of the arguments. So, change the order or change the name to “subtype-itemtype”
• MK: I kept the function notation basically in case people refer to it.
• MSM: So that pseudo function with its backwards arguments, as I see it, is a ship that has sailed.
• MK: Yes. And it always confused me which is why I got rid of it.

Proposal: Accept this PR?

Accepted.

See pull request #207

• RD: The spec references braced URI literal, which is the “U{“ part of the construct. What it needs to be is the “URI qualified name” instead. That’s the “Q{}local-name”.
• MK: Uhm…
• RD: If you look at the expanded QName section.
• MK: Yes, you’re right.
• MSM: I think there’s another place where braced URI literal is referred to that should perhaps be expanded QName. I’m looking at F&O section 10.1.2 under fn:parse-QName().

ACTION QT4CG-011-03: MK to change the references to URI qualified name in both QName-related functions.

• MK: In the last paragraph, the reference to BracedURILiteral is ok.

Proposal: Accept the PR?

Accepted.

See pull request #215

Waiting on actions QT4CG-009-0{3,4,5,6,7} on NW.

• RD: Make a separate subsection like RegEx pattern and point to it from both places.

ACTION QT4CG-011-04: NW to define the parse-uri/build-uri record types in a separate section

ACTION QT4CG-011-05: NW to update the history for parse-uri/build-uri to indicate that details are still being resolved

See pull request #222

Accepted at meeting 009, waiting for MK to resolve a merge conflict.

See pull request #228

Approved by RD, waiting for open PRs on F&O to be accepted, then NW will resolve any merge conflicts that arise and commit it.

Proposal: Accept the PR (after resolving merge conflicts)?

Accepted.

See pull request #230 and related issue #71.

Approved by CG.

• MK: The section on errors and optimization, which was always troublesome, gives implementations an awful lot of license to rearrange expressions in ways that introduce and eliminate errors. There’s a very limited set of exceptions for conditional expressions. What this does is take out that text for conditional expressions from 2.3.4 and generalize it into the concept of guarded expressions in 2.3.5. It gives similar guarantees for a number of other cases: “and” and “or” expressions where it says the first is guarded by the second; the same for multiple predicates, they behave like “and”.
  • … It also says that for loops, if you pull something out of the loop, it can’t raise an error if the loop is executed zero times.
• MSM: I’m not up to speed on this, if I’ve understood correctly, the upshot is that implementations can still reorder things, but if the reordered code raises an error, you have to work out if it would have raised the error in the original order.
• JL: Why is this in XQuery instead of XPath?
• MK: It’s in both.
• DN: I fully support this, but it just touches on the surface and we need to consider the topic of short circuit operators. Many languages have short circuiting operators. Maybe we can consider allowing the programmer to specify hints about possible lazy evaluation.
• MK: I’m very conscious that the whole treatment of error handling is still extremely informal and this is a small step in the direction of making it a bit more formal. Unfortunately, I’m not a formalist. It would be nice to have someone who could really do the formal semantics of error handling much more thoroughly.
  • … With respect to lazy evaluation, we’ve done hints before (ordered vs unordered) and they’ve been spectacularly unsuccessful. Implementors ignore them, users don’t understand them, so I have doubts about hints are likely to be of widespread benefit.
• RD: There is a formal semantics for XPath/XQuery 1.0 but that got abandoned.

Proposal: Accept this PR?

Accepted.