QT4 CG Meeting 133 Minutes 2025-08-19

• [X] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [ ] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [ ] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Wendell Piez (WP)
• [ ] Ed Porter (EP)
• [ ] 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 CG will take a short recess in late August. We will not meet on 26 August, 2 September, or 9 September.

The next meeting is planned for 16 September 2025.

(Items marked [X] are believed to have been closed via email before this agenda was posted.)

• [ ] QT4CG-116-01: Add a specific error code for unsupported options on doc and doc-available
• [ ] QT4CG-118-01: MK to make an incorrect type raise an error in #1906
• [ ] QT4CG-127-01: NW to diagram the JTree representing arbitrary XDM content.
• [ ] QT4CG-128-03: NW to compare the file: module against the equivalent XProc 3.1 steps
• [ ] QT4CG-131-01: MK to add a non-schema aware result.
• [ ] QT4CG-131-02: MK to expand on the $E := <e A="p q r"… example
• [ ] QT4CG-131-03: MK to change “invert” to “transpose” in the matrix example.
• [X] QT4CG-132-01: MK to add more examples for innermost, outermost, has-children and path with JNodes
• [X] QT4CG-132-02: MK to double-check the signature of innermost
• [X] QT4CG-132-03: MK to double-check stray text in h.i. in path
• [X] QT4CG-132-04: MK to add resize to the rectangle in the example of chaining method calls and flesh out the example.

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 #2168

• MK: The history of this is that we’d changed the eq operator to allow mutual comparisons.
  • … But we balked at the idea of making them equal for keys in maps because of compatibility implications.
  • … Basically, we’re being braver now: this is a more rational and consistent approach, and we assume that the number of users hit by the backwards compatibility issue will be small.
• JWL: We have no operator that says “is this the same type”?
  • … We’ve got castable which would allow you to infer one way.
  • … In the situations where you’d want to have a difference between the two, what could you do.
  • … The types are still distinct.
• MK: You could maniuplate the value if you wanted to keep them distinct.

Proposal: Accept this PR.

Accepted.

See PR #2167

• MK: We had a load of machiner that we added to lookup expressions (modifiers, type predicates, etc.)
  • … The JNodes proposal replaced all of that and I accidentally deleted more text than I should have done.
• MK reviews the PR
• MK: The text that’s being restored has been lightly updated to deal with JNodes.
  • … Added a note about out of bounds conditions.

Proposal: Accept this PR.

Accepted.

See PR #2160

• MK: This is the first half the work, but I don’t think we can accept it yet.
• MK: It only addresses the data model changes.
• MK: The position property of a JNode is discarded (replaced by the selector property, effectively)
  • … It has a parent, selector, or kind property.
  • … If a JNode represents a sequence of two or more items, an array or map that’s a sequence, then you have a children property, one child per item.
  • … If you’re a singleton, you don’t. So there’s an asymmetry there.
  • … That keeps the tree finite.
  • … That asymmetry is unfortunate, but less so than the current situation where sequences of more than one item are pretty unmanagable.

MK continues through the PR.

• MK: I reworked the second example as a table. I propose to do the same thing for the first example.
• MK: That’s my current thinking; there’s been a fair bit of discussion on the proposal.
  • … One of the ideas is that a sequence of length 1 should have children provided that you only go one level deep.
  • … An atomic value would have a child that contains the value, but that child wouldn’t also have a child.
• MK: One of the questions here is what is the consequence on the descendant axis. You want that axis to select each descendant exactly once.
• CG: I can’t give real comments, but I think this way forward is a good one. All the other approaches we’ve tried were much more inconsistent.
• MK: Okay, I’ll try to push forward.

See PR #2116

• JWL: We changed it so that the argument to the get is an ExprSingle but in some of the examples we still use Expr.
• MK: Okay, let’s take a look at that one.

MK reviews the XQuery diffs.

• MK: Yes. I see the places where Expr is still used in the examples.
  • … It’s probably best to use a variable in the get() to avoid the implication that it’s the same thing as the grammar rule.

ACTION QT4CG-133-01: MK to correct the use of “Expr” in examples for get()

• MK: The main subject is about the focus of the expression. There’s been a fair bit of discussion.
  • … The focus could be the thing to either the left or right of the slash. In both cases semantics that sort of make sense could be defined. But it’s so easy to get wrong, that I think it’s better to make the expression context-free.
• CG: I don’t think it’s that important, but I think one reason to support the context is that in all right-hand-side expressions, you can use the “.” and it doesn’t make any sense. This exception for the pseudo-function get() when it’s allowed everywhere else doesn’t make sense.
• MK: If the focus is on the right-hand-side, then you’d have to evaluate it for everything on the left hand side.
  • … It’s like “.” in a predicate; you end up with a lot of tests that aren’t very useful.
  • … I think the analogy with array:get is sort of a false one. Doing array:get on the right is applying the function to every item on the left. The get() pseudo-function is much more like using element() or node().
  • … We could restrict it to a constant, but that seemed like going too far.
• CG: There are lots of places where it doesn’t make sense, but maybe users will have uses for it. So many basic constructs in XPath that can be used to write weird things. It’s always up to the developer.
• MK: I don’t think we’re losing any functionality because you can use a predict.
• CG: But that’s true if we don’t have the get() pseudo-function at all.

Proposal: Accept this PR.

Accepted.

MK will merge this after completing his action.

See PR #2155

• MK: This has a technical flaw, there’s an ambiguity in the grammar.
  • … I’ve asked John Lumley for advice.
  • … I think it’s probably solvable with some subtlety.
• MK: The issue is to do with parenthesized expressions.

MK reviews the PR.

• MK: Patterns are now part of the section on template rules.
  • … Although path expressions between XNodes and JNodes look much the same, match patterns are distinct and can only match one kind of node.
• MK: The ambiguity is in how union, intersect, and except operators are applied.
  • … They’re not defined in terms of node sets anymore.
• MK: The text for XNode patterns is largely unchanged, but reorganized a bit.
• MK: JNode patterns are new.
  • … Always introduced by jnode(
  • … Both operands are currently required.
  • … It sort of mirrors the way that element() with two arguments works.
• MK: The default priorities broadly parallel elements and other things.

JWL demonstrates the grammar in his jwiXML processor.

• JWL: The inside and outside are the same, but the path from XNodePattern->ParentehsizedExpreP or ParentesizedPattern->XNode pattern is ambiguous.
• MK: Defining patterns for JNodes is the first part of a piece of work to talk about doing template rules on a tree of maps and arrays.

See PR #2123

Wait for JK.

See PR #2071

See PR #2019

Needs to be rewritten.