QT4 CG Meeting 177 Minutes 2026-08-25

DB, BTW give regrets.

• [ ] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:12-]
• [X] Michael Kay (MK)
• [ ] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [X] Wendell Piez (WP)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW) Scribe. Chair.

Proposal: Accept the agenda.

• MK: Can we do #2851 and #2854 early?
• NW: Sure.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 1 September.

No regrets heard.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-167-05: MK to write a proposal to change #2393 so the functions return JNodes
• [ ] QT4CG-167-07: NW to review tests for interpolated strings with edge cases in mind
• [ ] QT4CG-167-09: NW to close all “nice to have” issues at the end of October if they haven’t progressed
• [ ] QT4CG-170-01: RD to draft a proposal that attempts to address the lexical issues differently.
• [ ] QT4CG-174-01: MK to make an issue or otherwise address CG’s comments on #2734.
• [ ] QT4CG-176-01: NW to see about improving the linking for record types.
• [ ] QT4CG-176-02: MK to refine the strip-space option so that it takes account of historical defaults.

This section summarizes all of the issues and pull requests that need to be resolved before we can finish. See Technical Agenda below for the focus of this meeting.

See PR #2854

• CG: There’s a bug in the build
• NW: Oops. I’ll fix that.
• CG: I changed to using E2 and rewrote the prose a little.
  • … We can look at the older version of the PR.

CG reviews the issue, #2854.

• CG: The lookup should only apply to JNodes, so we have to special case by looking at the time.
  • … The problem in the function body is that a processor that does static analysis might raise an error.
  • … What can we do to allow this syntax but avoid the errors?
  • … Instead of writing the pseudocode in the spec, describe what should happen.
• CG: I added selector and navigational interpretations.
• MK: I’ve been through it and it looks okay.
• JWL: The first let $A shouldn’t be executable. If . is an instance of node
• CG: Right. It can never execute but a static error could still be raised.

Proposal: accept this PR.

Approved.

See PR #2851

CG begins by reviewing the issue, #2703.

• CG: This is about when we want to raise errors and when we want to raise errors.
• CG: There are four cases as outlined in the issue.
• CG: I thought it would be better to be lenient. We allow keys that may not produce results.
• CG: I’ve changed the rules to say that we don’t only accept QNames and strings, we also accept any atomic types.
  • … If the value can’t match, you just get an empty sequence.
• MK: What’s the expansion where we compare with node name?
• CG: We don’t coerce anymore and we use atomic equal so it doesn’t fail.

Proposal: accept this PR.

Approved.

See PR #2805

• CG: This is about function identities in general. We’ve noticed again and again that we have unresolved issues.
  • … The most important is that they’re completely implementation defined.
  • … You won’t know if the new version of a processor will do the same thing.
  • … It seems like we should drop them.
  • … But we still need rules to handle function comparision in places like fn:deep-equal.
• CG: I took some ideas from MK’s pull request and revised mine.
• CG: The basic idea is to talk about equavalence, not function identity.

CG walks through the proposed rules: the static form and captured context must be the same.

• CG: Hopefully, those two rules are sufficient. We have to allow for function rewriting, but we want the rules to work for most functions most of the time.

CG reviews the examples.

• MK: There are a couple of cases that aren’t discussed:
  1. Two named function references to different user-defined functions. Are we expected to compare the function bodies if they have different names?
  2. Functions create using partial function application.
• CG: For user-defined functions, I think we should compare the function body. That’s the “static form”.
• MK: And with partial application, it comes down to the fact that the captured context has to be the same.
• CG: When it comes to implementation, many cases are trivial. Those that are more complex, like comparing user defined functions, may be trickier for interoperability.
• MK: Going for 80% is good. The edge cases are going to be tricky.

Proposal: accept this PR.

Approved.

See PR #2831

Skip for this week.

See PR #2858

MK introduces the PR. The question is, how does the default value of a function parameter get evaluated? What are its static and dynamic context?

• MK: This effects primarily XQuery and XSLT, but with a small change in F&O.
• MK: In XQuery,
  • … You can use an ExprSingle or context value.
  • … Context value is an escape clause that lets you take the context from the dynamic context.
• MK: There are two ways a default can be defined.
• MK: There’s a note about what is not possible user defined functions.
• MK: In XSLT,
  • … We use the magic function current() for the context value.
  • … It’s another magic overload for current() …
• MK: There’s another note about what is not possible user defined functions.
• MK: In F&O,
  • … There’s a note about the way the syntax is used in F&O and how the semantics differ.
• CG: Would it be possible with XSLT to say something like data(current()) ?
• MK: That’s fine in the spec, but I don’t know if it’s been implemented!
• MK: We could try to introduce a current() function to XQuery instead of having magic syntax.
• JWL: Is there a reason why I couldn’t put an expression that uses current() in there?
• MK: In XSLT you can do that.

Proposal: accept this PR.

Approved.

See PR #2856

• CG: This one is mostly editorial.
  • … This one is related to the other PR about E1/E2.
  • … This PR adds a few things that had not previously been handled.
• CG: The most interesting is what we regard as being trivial or non-trivial.
  • … We differentiate between a range expression with to or an AdditiveExpr described as non-trivial.
• CG: I Changed that to make it a bit clearer.
• CG: In the list of navigational expressions, we had redundancies like a “a non-trivial FLWOR expression” because all FLWOR expressions are always non-trivial.
• CG: I basically completed the list with some things I thought were missing and made editorial improvements.

Proposal: accept this PR.

Approved.

See PR #2855

CG reviews the issue, #2818.

• CG: My proposal is to make both kinds of cast legal and remove an error code.
• CG: In XQuery,
  • … The grammar rules have been updated to have better names.
  • … I’ve removed XPTY0155
  • … And any array type and any map is a legal cast target.

Proposal: accept this PR.

Approved.

See PR #2814

(Moved before #2840 because of a dependency.)

• MK: In F&O,
  • … Deletes the “at risk” and the “value record” definition in favor of JNodes
  • … Changes the equivalent.
  • … We create it by casting, but the other proposal is to fix that.
  • … Some of the functions that depend on fn:array-members change because what is returned has changed.
  • … There are a lot of little changes like that.
• MK: The function itself now returns a sequence of jnode s
  • … Their properties and equivalence are provided.
  • … You now use the jvalue() function instead of ? value.
• MK: The array:of-members function has similar changes.

There’s a bit of intertwingle in the diff. And possibly the PR. Best we accept them both.

• MK: In XSLT,
  • … There are a number of references to array-members that have to be changed.
  • … The examples have been modernized.
  • … In xsl:array, by and large it doesn’t change except in its internals.
  • … We already had the situation where xsl:array was defined in terms of JNodes
  • … We’re making the functions consistent with the XSLT instructions.
• JWL: When the JTree is changed to accept item()* what happens if you pass in an XML node?
• MK: The data model already allows a JNode to wrap anything.
  • … It can be achieved, it just can’t currently be achived with the obvious way of using the jtree() function.
• JWL: So you can use it when you don’t know what kind of thing you have.
• MK: Yes, you can create trees in XML, for example, that consist of a single text node.

Proposal: accept this PR.

Approved.

• CG: There were various comments that weren’t addressed.
• MK: I think it’s best to merge and then review.

See PR #2840

• MK: This allows fn:tree to allow it to wrap any item.
  • … And there are some editorial changes and an updated example.

Proposal: accept this PR.

Approved.