QT4 CG Meeting 181 Minutes 2026-09-22

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

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 29 September.

AP gives regrets.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] 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-177-01: NW to put the progress graphs back in the minutes.
• [X] QT4CG-179-01: CG to fix the typo “or absent” in 14.6.5.

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

We ended last week on this one. MK walks through the PR.

The new line character is an implementation-defined string.

Proposal: accept this PR.

Accepted.

See PR #2878

• MK: Shallow-copy needs to have a clear model of how JNodes and sequences are processed.
  • … A shallow-copy mode should return the input unchanged if there are no other rules.
  • … That means we have to be clear about how everything is modeled in terms of JNodes.
• MK: There’s work on the data model, then most is in XPath/XQuery.

MK reviews the changes to the data model.

• MK: JPosition is dropped.
  • … There are four kinds of JNodes: a singleton array, a singleton map, a sequence, or a leaf JNode wrapping a singleton.
  • … I’ve adopted the notation <jnode> for describing the JNode trees:

<jnode kind='map' key='()' value='{ "a": 11, "b": [22, 33], "c": ()}'>
  <jnode kind='leaf' key='a' value='11'/> 
  <jnode kind='array' key='b' value='[22, 33]'>
    <jnode kind='leaf' key='1' value='22'/>
    <jnode kind='leaf' key='2' value='33'/>
  </jnode>
  <jnode kind='leaf' key='c' value='()'/>
</jnode>

• MK: That one is easy because it doesn’t have any sequences. Consider this one:

<jnode kind='map' key='()' value='{ "a": 11, "b": [22, 33], "c": (44, 55)}'>
  <jnode kind='leaf' key='a' value='11'/> 
  <jnode kind='array' key='b' value='[22, 33]'>
    <jnode kind='leaf' key='1' value='22'/>
    <jnode kind='leaf' key='2' value='33'/>
  </jnode>
  <jnode kind='sequence' key='c' value='(44, 55)'>
    <jnode kind='leaf' key='1' value='44'/>
    <jnode kind='leaf' key='2' value='55'/>
  </jnode>
</jnode>

• MK: Now the structure of the item differs for singletons or sequences.
• MK: I propose we invent a new axis. The idea is that it normalizes the representation so you don’t have to cope with the fact that they’re different.
• MK: There’s a bit of further detail about the properties of JNodes.

MK reviews the changes in XPath.

• MK: There’s a new axis called the item axis. It’s there so you can find the items in a sequence.

MK reviews the description of the item axis which applies only to JNodes.

• MK: The Selectors for JNodes section has been updated to use the new terminology.

MK reviews the examples in 4.7.5.4.

• RD: I’ve got two questions. Given that we’ ve dropped JPosition, that means that position is now implicit in the XML representation.
• MK: Yes. In fact, it’s in the key property.
• RD: In the array case, the key is the position.
• MK: Yes.
• RD: Is the item axis usable for a sequence? If you’ve got a sequence of XML elements, could you use the item axis?
• MK: No, it’s defined only on JNodes.
• RD: You could use a filter expression…with filter expressions you can access items in the sequence by position. Would that work the same with JNode sequences?
• MK: Yes. The only thing the item axis does is it gives you the flattening that singleton sequences and longer sequences have homogeneous behavior.
  • … For the vast majority of cases it isn’t needed. It’s not needed for JSON because there aren’t sequences. And it’s not needed in recursive descent.
• WP: For clarification, this is because we have sequences on values in JNodes and we have to deal with them.
• MK: Yes, that’s right.
• WP: And that’s in our world, not in JSON.
• MK: Yes.
• WP: What was the motivation for an axis rather than something else?
• MK: It’s the best solution I could come up with. I considered making it a property of the child axis, but …
• WP: I guess the uneasiness is what happens when you use it elsewhere.
• MK: Well, it’s defined on JNodes, so in any other case, like the other axes, it’ll give you an empty sequence.
• WP: My general sense is that this is nice and fits, but it’s going to be somewhat hard to explain.
  • … In particular, do we ever use this axis with a name?
• MK: I haven’t come across a case where you’d do that. But the situation I haven’t really explored yet is where you have a structure where a map can contain either a single map or a sequence of maps.
  • … But I don’t think anyone is going to do that. An array of maps is just easier.

Some discussion of using a function; it could be done, but it doesn’t fit into path expressions as nicely.

• JWL: If you use the item axis on something that isn’t a JNode, you’d get an empty sequence back. Do you anticipate something similar to the static analysis about using attributes on a text node for example.
• MK: I hadn’t worked out that detail.
• RD: If you can be sure that a value will never be a JNode, then it should be possible to emit a warning.
• MK: The only case where you get an error is if you apply it to an XNode. Like using the attribute axis on a JNode.
  • … It’s well defined in all cases because everything is a sequence.
• WP: And it combines the semantics of a couple of axis.
• MK: Yes, it’s roughly like the child axis on a sequence and the self axis for a singletone.

Proposal: accept this PR.

Accepted.

See PR #2912

MK proposes this one next because it’s closely related to the previous.

• MK: It drops shallow-copy-all mode which we introduced in an attempt at backwards compatibility that’s no longer needed.
  • … There are two parts, the shallow copy mode and the xsl:copy instruction itself.
• MK: I do define what happens with JNodes in the other processing modes, but it’s not significant.
• MK: The shallow-copy semantics can be expressed in a single template, modified to avoid errors.
• MK: There are some new examples.
• MK: The examples are repeated for the JTree.
• MK: One usability thing I discovered was “how do you start off the process?”
  • … With an XTree, you get an implicit document node. You don’t get that implicit behavior with a JTree.
  • … There are examples of deleting and renaming JNodes.
• MK: I’ve done a lot of work to think through the detail, but we won’t really know until we’ve implemented it.
  • … I think the mechanics are reasonably sound.
• MK: The other part is the shallow xsl:copy instruction itself.
• MK: The text has been broken into sections for clarity.
  • … The rules for XNodes have been refactored, but the semantics are the same.
  • … The section on JNodes is new.
• JWL: In the example where you’re renaming in the JTree.
  • … What does .* mean?
• MK: It’s a sequence pattern “.” that matches any item followed by “*” sequence occurrence indicator.
• JWL: Okay. That makes sense, but it looks odd.
• RD: I don’t see that defined in the grammar.
• MK: This is a JNode pattern defined in the XSLT specification.
• JK: I’m happy to see shallow-copy-all disappear. It never sat well with me. You said this was closely related to the previous PR. You introduced the item axis, how do they work in templates?
• MK: For this recursive descent pattern, we don’t need it. It purely uses the child axis which does the right thing.
• JK: It might be worth a note somewhere about that.
• MK: We don’t need it for this design pattern, but we might in other cases.

Proposal: accept this PR.

Accepted.

See PR #2910

CG introduces the PR.

• CG: How many features do we want to add? I tend to create new issues and PRs when things are simple and straightforward.
  • … This is something that came up in a use case.
  • … I thought two convenience functions would be helpful.

CG reviews the semantics.

• CG: I thought the binary module was a good place to put them.
• RD: This is for base64 data in a URL parameter instead of a URL. Would a slightly different name be better?
  • … This seems to indicate that the entire URL is base64 encoded.
  • … Maybe url-encode/url-decode-base64
  • … url-encode is a common name for encoding query parameters and the like.
• CG: We could add component.

Some discussion of the possibilities.

• MK: Where is this defined?
• CG: RFC 4648
  • … I’ve seen it outside URLs too.

Proposal: accept this PR.

Accepted.

ACTION QT4CG-181-01: CG to open an issue about a possibly better name for “the url base64url” function

See PR #2916

Skip for now, the PR didn’t build.

See PR #2881

• CG: I’ve revised the prose.
• CG: I tried to make the rules more explicit, separating XNodes and JNodes.
  • … And I’ve added some examples.
• CG: If we want a single function, I think this is a good compromise.
  • … Mostly what turned out difficult was defining different functions that do more specific things.
  • … Delete is easy, but update and replace are already complicated.
  • … I think one function to do everything is a good way forward, but we could add more.
• JK: I thought update was an XQuery thing but not an XPath thing.
  • … We’re introducing update to XPath?
• CG: Yes, there’s an XQuery update feature, but the idea here is to have something that works for both JNodes and XNodes.
• MK: This doesn’t have the conceptual problems of XQuery update: it doesn’t introduced pending update lists or anything like that.
  • … It’s a single function that returns an updated tree.

General consensus that this is a big change.

• CG: There have been some iterations. MK proposed one before; there have been other attempts.
  • … I ended up with this attempt.
• MK: I’d like to do a detailed review before signing off on it. I haven’t had a chance to do that.
• WP: This is the opposite of XProc; this is like having a mini transformation on the front end. It’s almost like pipelining in XSLT.
  • … I’m curious to see where it goes, but I don’t think it’s as important for XSLT.
• MK: In the context of JTrees, it’s significant because we don’t have node identity in JTrees.
  • … We can modify a tree but only change small parts. You can have a functional update that creates a new 100mb data structure while only changing three bytes.
  • … That’s much harder to achieve with an XTree because of the node identity problem.
  • … The shallow-copy is probably going to be linear in the size of the tree.
• RD: In the past, I’ve had some XSLTs that have 4 to 6 different phases. I wonder if this update function could simplify some of that?
• JK: It looks like in all of the examples the second argument is always a pattern.
• CG: It’s always a function because the input needs to be copied. The function is evaluated on a copy of the node. That’s why you can’t directly specify the path.
• MK: If you supply that pattern as a predicate, then the problem is that you’re going to have to search the whole tree to find matches. A function that selects them is probably going to be more efficient.
  • … Doing small updates to large trees with a pattern that you have to test against a lot of nodes in the tree isn’t ideal.

Ran out of time.