QT4 CG Meeting 144 Minutes 2025-12-02

Regrets: DB, CG

• [ ] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [ ] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO) [x:19-]
• [X] John Lumley (JWL)
• [X] Wendell Piez (WP)
• [X] Ed Porter (EP)
• [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 9 December 2025.

The CG will meet on 9 and 16 December, then recess for the end-of-year holidays, with the following meeting on 6 January 2026.

• [ ] QT4CG-143-01: CG to make another attempt at binary functions.
• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-143-03: JK to look for C14N test suites.

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 #2256.

DN and LQ (Liam Quin) have indicated that this PR is now ready for discussion. It’s on the agenda this week only as a heads-up. I propose that we discuss it next week. DN and LQ will join the call.

See PR #2256.

MK introduces the PR.

• MK: The motivation was to get rid of exception cases and to better align comparison and equality.
  • … In the status quo, you can’t use compare() to compare things that might be unordered (like QNames)
  • … Sometimes the ordering is arbitrary (true() and false()), but they are ordered.
  • … The ordering for durations is perhaps most problematic; it remains as it was, but it’s not an error to attempt to sort them.
  • … The data model impact is quite small, it just says they’re all ordered
  • … We introduce families of atomic types
  • … The XPath impact is largely the value comparison operators.
  • … The main change is that we remove a great table of comparison functions.
  • … Value comparisons are defined in terms of fn:compare().
    • … There’s a special case for NaN.
  • … We’ve lost a lot of examples with the table; I tried to make sure we have a reasonable set.
    • … We could add more.

ACTION QT4CG-144-01: MK to consider if any now lost value comparisons should be added as examples.

• MK: F&O now begins with an apology that it no longer defines any operators!
• MK: I’ve introduced the term contextually equal if fn:compare() returns zero (with the appropriate dynamic context)
  • … fn:atomic-equal() is now defined in terms of compare for numerics.
  • … Editorial changes to fn:compare().
  • … fn:deep-equal() now refers to fn:compare() returning zero.
  • … fn:distinct-value() refers to contextually equal.
  • … fn:index-of now uses the same contextually equal comparison; that is a technical change.
    • … It compares NaN as equal to NaN.
  • … Lots of textual change to fn:min() and fn:max(), but not significant
  • … fn:highest() and fn:lowest() get some editorial changes
  • … In fn:substring(), the arithmetic no longer refers to numeric-less-than operator.
  • … Arithmetic is still only defined on the duration subtypes.
  • … All the other changes are about removing the operators.
• NW: Why did we do it the way we did in 2.0?
• MK: I don’t know. Someone thought it was a good idea. But now that we’ve introduced the general fn:compare function so that’s just a lot of duplication.
• JWL: Are there any serious backwards incompatibilities?
• MK: The only one I’m aware of is NaN in fn:index-of().

Proposal: accept this PR.

Accepted.

(MK believes that CG agreed in principle.)

See PR #2324. See also PR #2282.

Wait until CG is present.

See PR #2313.

Wait until CG is present.

See PR #2301.

• MK: We had an external requirement to support this feature.
  • … I tried with a PI, but NW observed that was problematic.
  • … Here, I’ve added a cdata attribute to xsl:text and xsl:value-of.
  • … It’s expressed as an intent, and may be ignored.
• NW: Much better. It’ll still get lost across successive transformations.
  • … Is there any potential here for annotating the actual text() node?
• MK: We could, but then you’d have to define what happens to anything that operates on text nodes, for example what do you do with adjacent text nodes?
• JWL: If a text node is in a variable, you’re saying anything could happen.
• MK: An implementation could potentially store text nodes with a bit that indicates if cdata is requested.
  • … But I’m saying it’s only really likely to work if you pass it directly to a serializer.
• JK: Looks good and interesting. Where there any updates needed for what to do with serialization?
• MK: No, we haven’t made this a property of the text node. Sequence normalization will merge text nodes. I’ve basically left that largely unspecified.
• JK: So if you have three text nodes that are adjacent, and only the middle has the cdata attributes, what should I expect?
• MK: At the moment, I’m honoring that and only putting the middle one in a CDATA section.
  • … There’s still complexity here, what to do with combining characters.
  • … I don’t think we want to specify all that.
• WP: I like this a lot. I think it’s okay that this is like disable-output-escaping.
  • … There’s a bit of adjacency here with character mapping.

Some discussion of character mapping.

• MK: I wouldn’t expect the CDATA tags themselves to be subject to character mapping!
  • … Maybe we need a bit more detail, but I’d like to keep it a bit hand wavy.

ACTION QT4CG-144-02: MK to add notes about edge cases: sequence normalization and character maps for example.

Proposal: accept this PR.

Accepted.

See PR #2281.

• MK: These changes came from attempts to write tests and finding cases where it produced the wrong answer. I made spec changes in response to the usability experience of writing test cases. It’s also in response to comments on the original proposal.
• MK: I’ve introduced the term parcel again.
  • … The parcel simplifies the polymorphism in the array instruction.
  • … It’s now a dynamic error if you mix ordinary items and xsl:array-member instructions.

MK walks through the examples.

• JWL: In the for-each example that has apply-templates inside it:

<xsl:array for-each="*">
  <xsl:apply-templates select="."/>
</xsl:array>

• MK: There are two things it can do is create ordinary nodes or a single array member.
• JWL: But it can’t produce two array members.
• MK: That’s right.
• JWL: The heterogenous problem only applies when you use for-each.

Proposal: accept this PR.

Accepted.

See PR #2319.

• MK: When I wrote the issue, I thought there was a simple typo. But I discovered that for type patterns there was previous work that attempted to make the type patterns depend on the placement of the type in the hierarchy.
  • … But that makes xsl:next-match really complex.

MK reviews the priorities in the current proposal, section 6.3.3.2.

• MK: The conflict resolution rules are simplified.
• WP: I like it too. I wonder if there are any edge cases where we need to be able to find the default priority values?
• MK: It would be useful for writing tests!
  • … I XSLT, you have to bracket it with priorities above and below and make sure xsl:next-match does the right thing.

Proposal: accept this PR.

Accepted.