QT4 CG Meeting 184 Minutes 2026-10-13

• [X] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [x:06-]
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [X] Wendell Piez (WP)
• [X] 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 next meeting is planned for 20 October.

No regrets heard.

• [ ] 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.
• [ ] QT4CG-182-01: NW to review CG’s diff script

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

• NW: Anyone want to discuss it?
• MK: I think it’s fine.

Proposal: accept this PR.

Accepted.

See PR #2966

• CG: We discussed this before. I’ve incorporated MK’s comments. I think JK had comments on the new PR.
• CG: Mostly what’s changed is a response to MK’s comment. I mostly adopted it as proposed.
• MK: It was mainly to align the style of presentation for consistency with the rest of the spec.
• JK: As I’m reading this, it looks like the two meta-characters match only zero-length segments.
• MK: Yes.
• JK: But I use them in cases where I think of segments as being longer than zero length. And outside of multi-line strings, I find the notion of segmentation difficult to understand.
• MK: A segment is a tuple, a start position and a length. That’s a segment of the input string.
  • … This tells you if a particular meta character matches that segment.

Some discussion of the meta character rules.

• BTW: The meta characters just match a position in the string, not a part of the string.
• JK: If that’s the case, I think I’m justifiably confused. Segments suggests it’s a string.
• MK: We say segment in part to make it clear that it’s not a partitioning. Segments can overlap. This is an attempt to make the previous informal discussion more formal.
• JK: I just find it more confusing.
• MK: It’s not easier form a tutorial point of view but I think it’s more formally correct.
• RD: Would it make sense to add notes to help clarify things?
• MK: That’s what the “(informally, …)” remarks are for.

Some discussion of bringing them out as note markup.

• RD: Does this match a standard regular expression library, like PCRE?
• MK: It’s an attempt to match those conventions, as far as we can discern them.
• RD: If we could say it’s conformant to or compatible with some other spec…
• MK: I’m reluctant to do that.
• JLO: It took me a while, but I think I understand this formulation.

Some more discussion of clarifying the markup to distinguish between single and multi-line modes. There’s room for editorial improvement.

• WP: I think JK’s point makes it’s point. If JK is confused, then it’s confusing? I agree with BTW, but maybe a few editorial improvements could fix it. There needs to be some sort of gloss.
• JK: In the terminological layout that’s first presented, we discuss character positions. I’m surprised that’s not referenced anywhere here. Maybe that would fix it.
• WP: They aren’t partitioning.
• JK: Substring?
• MK: We use substring a lot, but it doesn’t have properties to tell you where they start or how long they are.

Some discussion of whether or not the term “segment” implies the absence of overlap.

Proposal: accept this PR.

Accepted.

See PR #2931

• CG: This is largely editorial. In the course of reading the prose and using the function, it seemed like it could be valuable to make some of the rules more strict.
  • … One of challeges is what to with key names that aren’t valid XML names.
• CG: We added an escape-names option. Whenever this option is enabled, the key will be converted to something that’s a valid element name.

CG outlines the rules proposed.

• MK: I haven’t really looked at this in detail yet. Can the escaping be undone by element-to-map?
• CG: Yes.
• RD: In the escaping rules, “_x” is mapped to “_x005F_”. That should be “_x005Fx_.

General agreement.

• JLO: Did you consider other ways to escape these? There are several, including one for URIs.
• CG: I haven’t looked at the URI approach. This was one that we already had.

Proposal: accept this PR.

Accepted.

See PR #2920

• MK: This attempts to clarify some things that could be discovered by very careful reading but should be more easily found!
• MK: Hopefully some earlier changes have made this clearer to see in the diffs.
  • … There’s an introduction to set some context
  • … The serialization section tries to put up front the choices about how results can be returned.
  • … Some things, like parameter documents, have been pulled out into a separate section.
  • … Choosing a serialization method is unchanged, but it’s been reorganized.
  • … There’s a new rule for what to do if the first item in a raw result is JNode or JSON.
  • … If you generate multiple documents with multiple URIs, you have to maintain their relationship.
  • … Replaced all of the wordy text about serialization options into a table.
• MK: Using xsl:result-document without an href has been clarified.
• MK: There are notes on the determinism of the xsl:result-document instructions

Proposal: accept this PR.

Accepted.

See PR #2911

• MK: There’s been a fair amount of comentary on this PR. Perhaps we should look at those as well.
• MK: Patterns that match maps and arrays by types looked too similar to patterns that matched them by content.
  • … There were some odd inconsistencies between type patterns and other patterns
  • … And a lot of duplication of functionality.
  • … This PR tries to provide the same functionality with less duplication and more clarity.
• MK: The classification of patterns changes.
  • … Mainly to reduce duplication in the spec.
  • … The syntax now splits between traditional patterns, XNodePatterns, and SimplePattern
  • … Simple patterns are to match other kinds of things.
• MK: Predicate patterns as such are gone.
• MK: Type patterns are gone. All the important cases are now covered by other syntax.
• MK: XNodePattern rules are unchanged.

MK introduces SimplePatterns

• MK: “.” matches anything. We can’t use bare names so atomic(name) matches an atomic. We also have map, record, array, and jnode patterns.
• MK: Doing instance of is retained from 3.0.
• MK: Atomic patterns don’t occur very often in the top level, but they appear within other patterns.
• MK: Sequence pattersn don’t appear at the top level. They’re an ordinary pattern with an occurrence indicator.
• MK: Record paterns match nominative records.
• MK: Array patterns match arrays; it looks very similar to the type. That might be confusing.
• MK: JNode patterns don’t change, except for the predicates being refactored out to a separate part of the spec.
• MK: The rules for default priority have been reorganized but aren’t supposed to have changed.
• RD: Is it possible to use a function as a top-level of a pattern?
• MK: It is for XNode patterns. You can start with the doc function; but it isn’t for new ones. They don’t have hierarchical selection.
• RD: Do these need to be reserved function names? What if you have a function called array
• MK: You can only use a very few functions at the top level.
• JLO: Why is it impossible to generalize those patterns to match both XNodes and atomics and records?
  • … Can we generalize the new patterns to match XNodes as well?
• MK: I’m not sure what kind of generalization you mean.
• JLO: One that either deprecates the current patterns or makes it so that we don’t need a separate set of patterns.
• MK: Generalizing the patterns for element paths is difficult. It would conceptually be possible to do it for JNodes.
  • … We could use the same kind of syntax with / to select JNodes as we do XNodes
  • … But I’m put off by that idea because I think it’s unlikely that users will ever want to write a template that matches both an XNode and a JNode
  • … This makes the distinction visible to both users and the compiler
  • … I considered using a different attribute, but opted against it.

Some discussion of the mixed case, like applying templates to collection().

• JWL: I can imagine wanting to match a function item in some complicated cases. You can always do it with predicates. If you opened that can, you’d have deal with the fact that array() and map() are also functions.
• MK: We don’t have all that much machinery for introspection on functions. I’m not sure we could improve on the syntax.
  • … Doesn’t seem obviously useful.
• JLO: It’s a little confusing that the any pattern can only match XNodes.

MK walks through the whole syntax from the top level.

Some discussion of where you factor in the predicate logic.

Proposal: accept this PR.

Accepted.

Any last words?

Put them on the agenda as issues to be closed next week.