QT4 CG Meeting 163 Minutes 2026-05-05

• [X] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [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 12 May 2026.

Possible regrets from DB.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [X] QT4CG-144-01: MK to consider if any now lost value comparisons should be added as examples.
  • Decided to make no further change. I reviewed the examples of fn:atomic-equal and fn:compare and decided they are adequate.
• [X] QT4CG-156-01: MK: add reference to data model in F&O 9.2
  • Overtaken by events, already in F&O
• [X] QT4CG-156-03: MK to revise PR #2516 in light of the comments.
  • Done in PR #2609
• [X] QT4CG-158-01: MK to revisit the Conformance section to revise in light of #2556 error changes
  • I decided to make no change. I don't think we need a conformance feature for every aspect of processing that is implementation-defined.
• [X] QT4CG-158-02: MK to add system-properties() keys for file and binary support
  • Done in PR #2603
• [X] QT4CG-160-01: MK to fix the markup error in method/method call in #2578
  • Done in PR #2604
• [ ] QT4CG-160-02: NW to think about how to promote the dated drafts for broader community feedback.

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

• MK introduces the PR; perhaps there hasn’t been sufficient time for review.
• MK: This is entirely XSLT.
  • … The motivation for this is that xsl:array-member has been through several iterations. The challenge is that we need a sequence that doesn’t get flattened.
  • … One solution was a zero-arity function item to represent that sequence.
  • … This PR changes that to return a JNode who’s value is the sequence.
  • … This allows you to combine the contents of an existing array with newly constructed array members.
• NW: I think that’s a real improvement.
• JWL: An xsl:array-member can only be under an xsl:array?
• MK: No, you can put it in a called template or return it from a function.
• JWL: But it always returns a JNode
• MK: Yes
• JWL: But xsl:map-entry returns a map.
• MK: Yes; but I’m thinking of changing that.

Some discussion of the array concatentation example.

• JWL: On that example, if we replaced the sequence with xsl:array-member/@select would we then get a nested array?
• MK: I’d have to think hard about that.
• JWL: I think we need an example of that.
• JLO: What happens if there’s an arbitrary sequence, not a JNode?
• MK: No, what xsl:array does if you supply things that aren’t JNodes it adds them as individual items.
• WP: It might also be helpful in this context to show some more examples, with nested arrays for example.

Proposal: accept this PR?

Accepted.

See PR #2611

• MK: This is a now presented as a free-standing PR, not bundled with anything else.

MK describes the semantics of the function and reviews the examples.

• MK: The matches, replace, and other functions become methods on the regex record.
• MK: I’ve added an _implementation field for implementation-defined extensions.
• MK: There are questions of encapsulation here; if you take these methods out of the record, things may go badly wrong. So don’t.
• JWL: In the example $regex ? replace(…) threw me a bit because we usually don’t have spaces.
• MK: I’ve played with both coding styles, it’s not clear what the best answer is.
• DB: Is the spec consistent about the spacing around that question mark, or whether it should be.
• MK: The spacing doesn’t effect the behavior just the readability.
• DB: But there’s no recommendation and the spec isn’t necessarily going to be consistent.
• DB: What’s an anticipated use of the _implementation field?
• MK: One way of implementing this would be for all the information about the compiled regex to go into the functions themselves. I felt that might lead replication. Another way of implementing it is to make this a special object internally that behaves like a map or record but has some hidden magic not exposed at all.
  • … This makes it a little more explicit that there’s magic; that there’s state.
  • … It might be as simple as a checksum so that the implementation can be sure it was one that it constructed.
• DB: Is that a slippery slope? Do we care?
• MK: Yes. We might learn from experience whether that’s useful or not.
• CG: It was the _implementation option that I first looked at. I think we should drop it if we don’t have a serious use case for it. We don’t use this syntax anywhere else. To me, everything in this function looks like an implementation optimization, not something for the user to use.
• MK: Well, obviously the alternative is caching; the problem is that it imposes a cost and you don’t know if that cost is going to deliver a benefit.
• CG: It would be good to see some use cases. But my impressions are personal.
• MK: One case is in XSLT pattern matching. You might want to use the same match conditions against very many nodes.
  • … You could say that there’s an obvious case for an optimizer to do the work there, but I don’t know…I like to give users the opportunity to be explict.
• JLO: My points have been covered; I’d like to drop _implementation. I think if we do want something here, I’d like something more symbol-like.
  • … With respect to style, I’d put spaces around the ! never the ?.

Some further discussion of the readability of the example.

• JK: Just a quick note that I’m greatful for the proposal. I represent a kind of use case in that one of my applications is a series of global changes to a large number of files and uses a lot of regular expressions. If you’re doing 200 regex replacements against every text node in a large collection of documents, you want it to be faster.
• MK: The current Saxon implementation pre-compiles regular expressions if they’re compile time constants. There are cases where it’s computed at runtime and still used repeatedly.
• JWL: The use of tokenize there is confusing.
• WP: I can see places where it would be very nice to have this. My question isn’t about the style, but how is ! different from ? in that location. I think there might be more clarification needed there.

MK agrees to take this feedback and make another pass.

• CG: We have functions like transform that have a cache option; maybe that could be a useful approach here?
• WP: In general, I need an education in caching.

See PR #2610

MK introduces the topic. It was CG’s issue, but it’s MK’s PR.

• MK: I’ve rewritten the grammar to allow a leading slash to start at a JNode.
  • … The amount of change isn’t all that great.
• MK: There’s a new section about what a path beginning / means.
  • … / by itself is /.
  • … It spells out the other possibilities for every item.
  • … The case where we wrap a map or array in a jtree is the one that concerned me. It’s basically a no-op, but it’s allowed for generality.
• MK: There’s a new section about what a path beginning // means.
  • … It’s much the same
• JWL: If you’ve got a map inside a map and you then go down, do a select, get to the inner map, what does / mean then?
• MK: The complex cases are where you do a downward selection then have a predicate that uses /.

MK illustrates a complex case: $map//name[//city=’London’]

• MK: You’ve got to think quite hard about whether or not //city causes an upward naviagation and if it does, where it goes.
  • … In this case JNodes are selected, so it’s actually going to go up to the $map which is the root of the tree.
  • … But there are other cases I worry about where the root in the predicate might be different.

MK proposes $map//name => jvalue(.)[//city='London']

• MK: That’s different.

Some discussion of how you’d assign variables, make them JNodes, etc. Lots of possibilities.

• JWL: It depends on whether or not you did type coercion in a variable.
• CG: Thank you for the PR. One reason for creating the issue was that many people tend to write a and /a and they use them in the same way when the start at the root. It can be hard to explain the differences to users. If you make it easy for the everyday user, that will be an advantage.
• MK: One of my concerns is that static analysis is difficult when we don’t know if we’re dealing with XNodes or JNodes. But that’s an implementation problem.

Proposal: accept this PR.

Accepted.

See PR #2609

MK proposes to skip this until next week.

See PR #2606

CG introduces the topic.

• CG: This is a special case for file:copy and file:move. You can specify a source and target, when the target is located inside the source, that can lead to cyclic behavior.
  • … I decide to make this an error.

Proposal: accept this PR.

Accepted.

See PR #2603

MK proposes to skip this until next week; it’s being revised to improve clarity.

See PR #2601

MK reviews the PR.

• JWL: The error code for the timezone one has a formatting problem. (-PT14H gets split between “-” and “P”)
• JK: I would prefer to see something similer to 001 for values outside an expected range. The complaint was that FORG001 already covers a lot of problems. But as MK said, that’s about casting and the data type, not with whether it’s in an expected value.
• MK: I think it was done this way because when you do casting we do allow the value 24. But on this function we don’t.
• JLO: I like JK’s idea of having more general error codes here.
• MK: Let’s get rid of FODT006 and use FORG001 there as well.

See PR #2595

• JK: This is really editorial; or it’s intended to be.
  • … It’s motivated by checking on the data types. I was curious to know if regexes could be a data type.
  • … There was text in Predefined Types that was largely repeated from Types adopted from XML Schema.
  • … I’ve moved them and put them closer together.
• JK: I also took the opportunity to present items that hadn’t got formal definitions: in particular, xs:numeric
• JK: And I added a lot of cross references.

Proposal: accept this PR.

Accepted.