QT4 CG Meeting 137 Minutes 2025-10-07

• [ ] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [ ] 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 next meeting is planned for 14 October 2025.

JWL gives probable regrets.

(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
• [X] 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
• [X] QT4CG-131-01: MK to add a non-schema aware result.
• [X] QT4CG-131-02: MK to expand on the $E := <e A="p q r"… example
• [X] QT4CG-131-03: MK to change “invert” to “transpose” in the matrix example.
• [X] QT4CG-133-01: MK to correct the use of “Expr” in examples for get()
• [X] QT4CG-135-01: MK to correct attribute rule 5/d to use the schema component name

We currently post “latest draft” publications, which change with every accepted PR, and PR drafts which expire and get deleted after a month or so. As things become more stable, should we consider publishing stable, dated drafts?

• Update the status sections to indicate immutable status
• Publish them to a dated URI space, e.g. /specifications/2025-11-04/...
• Link to (at least the most recent) dated versions from the homepage

Discussion:

• CG: For me, what’s important is that things stop changing.
• NW: This is about pointing to something that’s stable.
• RD: Is it possible to publish a candidate recommendation.
• NW: No, that’s not something we can do.
• JWL: There’s an implication that once you’ve put out a stable draft; you’d rather not produce backwards compatibility issues.
• JK: Would you adjust things in the test suite?
• NW: I’m not sure we have the manpower for that; but we could publish a dated test suite.
• JLO: A think a dated draft is counter productive. People will assume that all of it are stable. It might be more interesting to label things stable if they’re stable.
• RD: The backwards compatibility has been broken in the past at various stages in the process.
• MK: I don’t think this is primarily about stability; it’s about having a version that people can cite so that documentation of a product can refer to a cited draft.
  • … Because the spec is changing, you want to be able to refer to snapshots of it as it was changing.
  • … At present, there’s no record of what has changed.
• JLO: We could use git tags for this purpose.

Straw poll: would you support publishing “tagged draft”

Most in favor.

ACTION: QT4CG-137-01: NW to make a concrete proposal for tagged drafts

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

• MK: The background is that we made numeric comparison transitive in some places but not everywhere.
  • … This PR bites the bullet and makes them transitive everywhere.
• MK: I tried it in a test branch; most of the failures were in assertions in test cases (doubles compared with decimals).

MK reviews the changes in the draft.

• MK: The rules for general comparisons change so that untyped atomic values are cast to the type of the other operand. That mitigates some of the changes.
  • … Updated appendix H, but it’s non-normative.
• MK: In Functions and Operators most of the changes are in how the functions are defined.
  • … I plan to do further work to reduce the number of redirections to get to the actual rules.
• MK: It doesn’t change all that much content, but it’s certainly a change that will break a few people’s code, but on the whole the level of impact is bearable.
• RD: In the first section on casting from untyped atomic, should we mention xs:integer as well as xs:decimal?
• MK: If you have a general comparison to an integer, you cast the untyped atomic to decimal. So 1.1 cast to decimal is going to be not equal to the integer 1.
• RD: If you have an integer 1 and an untyped 1…
• MK: Those will be equal because an integer 1 and a decimal 1 are equal.
  • … Doubles compare with integers without problems as well.
• JLO: So eq will never change the type, right?
• MK: An eq converts an untyped atomic to a string; never ot a number.
  • … But = does convert.
• JLO: Is this op:numeric-equal()?
• MK: Yes.
• JLO: I think this makes sense, but I think it will break a lot of code.
• MK: I was pleasantly surprised that it didn’t break a vast number of tests.
  • … Of course, the test suite is completely atypical.
  • … It’s already dicey if doubles are going to compare equal because of rounding errors.
• CG: I implemented a prototype of this and I was also positively surprised that there were only a few edge cases that I had to investigate in detail.

Proposal: accept this PR.

Accepted.

See PR #2222

CG introduces the PR.

• CG: We should also look at issue #2221; fn:unparsed-text and bin:decode-string have different rules for input encoding.

Some discussion of the difference between UTF-16, UTF-16le, and UTF-16be.

• RD: What about UTF-32?
• MK: I don’t think we should extend the set of manditory versions.

Some further discussion of the differences.

• CG: I think we should always interpret the byte-order-mark if there is one.
• MK: One observation is that bin:decode-string can start in the middle of the string.
  • … You can’t look for a BOM there.

Some discussion of what it means if you start at a continuation byte? It’s currently unspecified.

• NW: The fact that bin:decode-string starts in the middle makes things hard.
• CG: I think we should always interpret the BOM.
• JWL: Then you have to be able to provide the BOM in the result.
• JLO: Maybe we should say that the caller of bin:decode-string must always provide the encoding and other necessary features.
  • … And maybe provide another function to do the heuristics.
• CG: If you specify an encoding, you might still want to skip those bytes.
  • … But what does “offset 0” mean then?
• RD: For 0 I think it makes sense for that to be the start of the file.
• RD: It does make sense to explicitly specify which encoding you want; in the middle of a string, you don’t know if the alternating 00 and ASCII characters are little-endian or big-endian. So I agree with JLO that we should always pass the encoding.
• JWL: I think this implies that there needs to be another function that returns a property record of this sort of stuff: there is a BOM, encoding, etc.
• RD: There is a WHAT-WG encoding specification. Maybe refer to that or the relevant Unicode specs on byte order marks.

CG will review and make another proposal.

• RD: I think the two functions should be consistent.
• JLO: I’d really like to see the functions.

• CG: The reason for this small PR is a test case where fn:base-uri() was invoked with an invalid static base URI.
• MK: My only comment is that it seems a bit odd to raise an error on something that retrieves the URI. If the data model is allowed to have an invalid URI, it seems odd to report the error when you retrieve it.
• CG: But when would that happen.
• MK: Data model construction is a bit out of our control, but you could impose a constraint in the data model to enforce it.

CG reviews the test case, #2148.

• NW: I think the constructor failing would be better.
• JLO: I think the constructor should fail.

ACTION: QT4CG-137-02: NW to try to review the spec vis-a-vis #2148