QT4 CG Meeting 025 Minutes 2023-03-07

Regrets: BTW, DN

• [ ] Anthony (Tony) Bufort (AB)
• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:15-]
• [X] Michael Kay (MK)
• [X] John Lumley (JL)
• [ ] Dimitre Novatchev (DN)
• [X] Ed Porter (EP)
• [X] C. M. Sperberg-McQueen (MSM) [:08-]
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW). Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

• MK: First item was a discussion on closing various issues. I believe we agreed to close some but didn’t make an action.

ACTION QT4CG-025-01: NW to close the issues we agreed to close in meeting 024

• RD: Should be able to close the parse HTML issue as well.
• MK: If you opened an issue and you think it can now be closed, I think go ahead and close it.

Accepted as amended.

The next meeting is scheduled for Tuesday, 14 March 2023.

ATTENTION: This meeting is scheduled at 16:00 local time in Europe. The United States will be on Daylight Saving Time starting on Sunday, 12 March 2023. Until Europe and the UK switch to summer time (on 26 March 2023), this meeting will be one hour later in the United States starting next week.

No regrets heard.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
• [ ] QT4CG-016-08: RD to clarify how namespace comparisons are performed.
• [ ] QT4CG-023-01: NW to review the stylesheets for functions across XPath and XSLT
• [ ] QT4CG-023-05: NW to put record types on an agenda.
• [ ] QT4CG-024-01: MK to add namespace-uri-for-prefix argument changes to the compatibility appendix
• [ ] QT4CG-024-02: DN to develop an alternative proposal for deep-action.
• [X] QT4CG-024-03: NW to create issues for improving fn:deep-equal

Contrary to the remark above, this is not a small issue. But it’s a bug and deseves high priority. I propose a 30 minute time box on this issue so that we do have time to resolve some low hanging fruit.

See pull request #375.

• MK: I worked through all the changes in XQuery, but haven’t done the corresponding changes on XSLT. If we agree with the design, it’s fairly mechanical to translate to XSLT.
  • … In the course of doing this, I found that the two sections on variable and function declarations had become unstructured and unweildy. I reorganized them but that makes the diff hard to read.
  • … What should be the static and dynamic context for the expression that defines a default value?
  • … Using the same static context as variable declarations fails to satisfy the goal of allowing user-defined functions to have access to the context item and default collation.
  • … First thought was to use something different for the dynamic context, but that makes the inconsistent. The “static item context type” for example becomes meaningless if the context item is taken from the dynamic context.
  • … I thought about defining a custom context, we could do that, but it’s a little bit daunting.
  • … I also thought about cutting back on our ambitions and allowing only the static context. That’d lose the ability to use the context.
  • … The proposal here introduces a new function that you can call in the initializing expression that give you access to parts of the callers context.
  • … I’m not enormously fond of the solution, but…
• RD: As a goal, I think it’s a good to make it possible to get to the dynamic context.
• CG: I think that it would be good to add an example of a function item. I outlined it in a comment on issue #375.

let $filter := function(
  $item := caller-context()?context-item()
) {
  $item = 'Jupiter'
}
return //planet[$filter()]

• MK: Adding examples is part of the next phase if the design is accepted.
• CG: Can we call the function context() and the item item?
• MK: When we get to talking about the spelling, you’re in the home stretch.
• JL: Couldn’t this be generalized to solve questions like “what’s my current mode” in XSLT?
• MK: Yes. I adopted a fairly extensible design on purpose.
• JL: Would we also have to be fairly careful about security implications? About being able to see things that the compiler has got rid of.
• MK: For access to the static context, that could be an issue. It’s nice to be able to discard parts of that.
• RD: In the current spec, where we’ve done . for the context, all of those will need updating.
• MK: Yes, if we do this, we’ll have to update the standard functions.

MK isn’t sure that it makes sense to attempt to go through in too much detail. Reviews the non-diff version because of the changes caused by reorganizing things into subsections.

• MK: Most of the change is in 5.18.1…
• JL: Why are the record types functions rather than just values?
• MK: Probably to emphasize that you expect them to be evaluated lazily; that’s probably particularly true of last().
  • … We could leave out the brackets and make them properties rather than methods.
• CG: One advantage of a simple map is that it makes it clear that the values you get are specific to when the function was called.
• RD: I’m in favor of them being ordinary variables.

ACTION QT4CG-025-02: MK to make the context function properties simple values instead of functions

• MK: I think we’re looking for agreement in principle.
• CG: The $ character needs to be removed
• MK: Yes, that’s a typo.
• JL: In XSLT, we have a parallel where it’s a variable (in catches and things).
• MK: Yes, we define magic variables there. There are other places where we define magic functions.
• RD: XQuery does the same thing for variables in the catch expression.
• MK: If it’s a magic variable, what namespace does it have to be in?
• NW: We can leave it a function and not have to answer that question!
• CG: A function also makes it clear that it changes when called in different places.
• JL: Can you bind it to a variable?
• MK: Yes, but the scope is going to be in your initializer so it can’t escape.

Proposal: accept this PR in principle, action to MK to expand it

Accepted.

ACTION QT4CG-025-03: MK to revise and expand technical detail in PR #375

See pull request #378.

• RD: This is a straightforward change; I’ve changed “must” to “will” in various cases where we’re referring to ASCII lower case and changed “unparsed” to “unknown”.

Some discussion of the “unparsed-entity-public-id” accessor. It’s not relevant because HTML5 doesn’t have unparsed entities.

ACTION QT4CG-025-04: RD to remove the note in 15.5.15 of functions and operators.

Proposal: Accept as ammended?

Accepted.

See pull request #371.

• MK: This was editorially updating some things to say 4.0 instead of 3.0.

Proposal: Accept this PR?

Accepted.

See pull request #364.

• CG talks us through the changes to the switch expression.
  • … In the new version you can supply arbitrary lists of expressions in the switch expressions. If any expression matches, then the case is accepted. If it’s an empty expression it works as before.

Proposal: Accept this PR?

Accepted.

See pull request #363.

• MK: This was a fairly obvious omission. I’ve added a few notes and clarified what schema types are.
  • … Local union type and enumeration types are “schema types”
  • … etc.

ACTION QT4CG-025-05: MK to correct the accidental deletion in 3.6.2 of XQuery

• MK: The new rule in 3.6.2 is what was missing.
  • … The rest is expanding on the definitions and editorial improvements.

Proposal: Accept this PR as amended?

Accepted.

See pull request #355.

ACTION QT4CG-025-06: NW to fix the “blue boxes” in the serialization specification

• MK: Adds two implement-defined features

Proposal: Accept this PR?

Accepted.

See pull request #344.

• MK: This one is a little bit more substantial.
  • … Tidies up the language about iterating in 4.12
  • … Slightly refactors the syntax but essentially let’s you have two for clauses. It’s syntactic sugar to let you write expressions in XPath that look more like XQuery.
• MSM: The refactoring of SimpleForBinding seems to make a grammatical change is that intended?
  • … If I’m reading the grammar correctly, in the old grammar the keyword member is optional before the first keyword binding in a for, but not in one following a comma. Now it is allowed in front of any variable binding.
• MK: Yes, that’s correct. Now you can control member for each one independently.
• RD: I created an issue (#49) for this.
  • This goes into the discussion of the for-member functionality that was added before we convened as a group.
• MK: Let’s check what the non-diff syntax looks like.
  • … The member keyword doesn’t propagate. If you say member your iterating over an array; otherwise you’re iterating over a sequence.
• MK: The PR does the same thing for let.
• JL: We have an error case when its not an array and you use member. I didn’t see an error code.

ACTION QT4CG-025-07: MK to update the text about for/let changes to use use definitions and termrefs correctly. ACTION QT4CG-025-08: MK to add an error code for the case where member is used on something that isn’t an array

Proposal: Accept this PR?

Accepted.

See pull request #347.

• NW walks through the changes.

ACTION QT4CG-025-09: NW to add the parse-uri and build-uri tests to the test suite

Proposal: Accept this PR?

Accepted.