QT4 CG Meeting 146 Minutes 2025-12-16

Regrets: SF, RD.

• [X] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [ ] Sasha Frisov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [ ] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [ ] Alan Painter (AP
• [X] Wendell Piez (WP)
• [ ] Ruvim Pinka (RP)
• [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 6 January 2026.

The CG will not meet for the remainder of 2025. Happy New Year, everyone!

• [X] 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.
• [ ] QT4CG-144-01: MK to consider if any now lost value comparisons should be added as examples.
• [X] QT4CG-144-02: MK to add notes about edge cases: sequence normalization and character maps for example.

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

MK introduces the PR.

• MK: This brings a few details about canonical JSON serialization to the reader’s attention.
• MK: Map entries are sorted; added a note pointing out how that sorting must be done.
• MK: The rules for canonical numbers in RFC 8785 are quite complex.
  • … I’ve added a note that if the output is not canonical, output decimals (including integer) as the string value (not scientific notation).
  • … For strings, I’ve restated the escaping rules for convenience; they differ from our usual rules.
• MK: In JSON canonicalization, the RFC takes as the input an existing JSON document, where we take an XDM value representing the tree. I thought about wording it that way, but that gives too much freedom for numerics. We say that our rules are effectively a mapping to the implicit data model of I-JSON.

Proposal: accept this PR.

Accepted.

See PR #2329.

MK begins by reviewing the issue and the alternate names proposed.

• MK: I think fn:insert-separator has the most support.
• CG: I can see that there are concerns about fn:sequence-join. I would be fine with several of these. Make it more explicit what the function does; I’d also revert fn:array-join at the same time.
• JK: From my perspective, the function under discussion is similar to fn:insert-before. If that’s the case, I’d like to see greater parity between them. I prefer fn:insert-throughout.
• WP: JK’s point being taken, maybe “connect with” or “connect by”? I like any of the ones that give you a hint.
• JWL: The separator can be a sequence, can’t it? And it can be empty.
  • … So there’s an argument for insert separator*s*.

Proposal: we have consensus for fn:insert-separator.

Accepted.

And MK to merge when it’s changed.

• CG: Maybe if there are other features that we think we could revert. Maybe we should do that now?
• MK: I think the problem is that you discover the problems as you try to use them.
• CG: I opened one issue for the predicate filters.

See PR #2324 and #2282.

CG introduces the topic.

• CG: We had some discussion on bin:decode-string. We currently have a bin:decode-string with an offset that defaults to 0. There are too many ways to similar things. Can we make it more composable?
  • … My proposal is to invoke bin:part wehnever an offset is provided.
  • … After that, we don’t have to look at the offset and size anymore
  • … Then we invoke bin:infer-encoding to retrieve the effectiver encoding.
• CG: I’ve extended bin:infer-encoding to accept an encoding argument. That’s for resolving UTF-16 endianness. A processor may have a heuristic if no encoding is provided. If there’s no byte order mark, the encoding specified is used.
• CG: There’s no reference to fn:unparsed-text and the rules are simpler again.
  • … Whenever you have substrings in your binary data, if the substring begins with a BOM, then it will be respected.
• MK: I’m okay with that.
• NW: I think that works for me.
• JWL: Are there cases where you could be building a binary structure where you’ve got combining strings that have different byte order marks inside them?
• CG: In this case, you could have different byte order marks.
• MK: I can imagine that happening in an archive format like ZIP.
• JWL: It might be worth adding a note about that.

Proposal: accept #2342, drop #2282

Accepted.

See PR #2313.

CG introduces the issue.

• CG: Right now we have more than 100 built-in functions with default values.
  • … I noticed while implementing them that we have two types of default values.
  • … For some functions, you get identical behavior for absent value or empty sequence
    • fn:string-join
  • … For others, you get different behavior for absent value and empty sequence
    • fn:node-name
• CG: The problem is that looking at the signature, you can’t tell what will happen.
  • … You can look it up, but that might be tedious for 100+ functions.
• CG: Another example is the case where there’s a default value but it can’t be the empty sequence.
  • fn:sort
• CG: My attempt was to make all this consistent in one way. The approach I chose is one we have to discuss.
  • … Most of the function signatures are hard to read in the diff version.
• CG: My thought would be to change the rules for intepreting function signatures for XQFO so that you can look at the signature and know what is going to happen.
  • … If the value supplied matches the type, that value is used
  • … If no value is supplied, the default value is selected
  • … If the value is teh empty sequence, the default value is selected
  • … Otherwise a type error
• CG: This would let you know what is going to happen just by looking at the signature.
• CG: So for example, in fn:string-join, the ? is removed from xs:string because the default is used if you supply an empty sequence.
• CG: Many of the specific rules from the prose are no longer required.
  • … That prose is hard to find because there’s a long history. So this also makes the whole document more consistent.
• MK: I’m very sympathetic to the intent: both to increased consistency and relying more on declarative ways of describing the semantics.
  • … I’m concerned that this appears to attach semantics to signatures in the F&O spec that don’t apply to the same syntax used for a user-defined function in XQuery or XSLT.
  • … I’m also concerned that there’s possible confusion between the notation here and the symantics of function calls defined in XPath.
  • … For example “the supplied option matches” doesn’t mention the coercion rules.
  • … As it happens, I don’t think coercion plays an especially significant rule because we don’t coerce to or from an empty sequence.
• MK: I wonder if we could do this with an alternative way using the properties mechanism.
  • … We adopt some markup convention that allows the rule to be expressed in the properties section.
• CG: I had similar thoughts.
• NW: The rules that only apply to F&O functions is confusing.
• JK: Could we hear more about the fn:adjust-dateTime-to-timezone? The empty sequence has a different meaning there.
  • … I’m concerned that people may be using empty sequence to avoid the default.

Some discussion of whether or not the rules provided cover this case.

Some discussion of how this change would effect test generation.

• WP: So the item xs:integer would be satisfied with an empty sequence?
• NW: What’s the markup approach?

Some discussion of the fn:array-get function because it’s two argument form can’t be represented by any default for the third argument.

• MK: We need an “empty sequence = default” notation.

ACTION QT4CG-146-01: NW to attempt to provide a markup solution for argument defaults

See PR #2336.

• MK: This is probably too big for today.
• JWL: I’ll try to run my grammar generators over it and see if I can find out if there are any ambiguities.

See PR #2323.

• MK: This arose because I wondered why we can’t use simplified stylesheets for JSON documents.
  • … I don’t use simplified stylesheets very often, but sometimes they are handy.
• MK: The essential change is that instead of the outermost element being a literal result element, it can be any instruction.
• MK: The stylesheet that unsimplifies the stylesheet is about the same.
  • … The top level match pattern is no longer “/”, it’s now “.”.
• NW: What about silly things?
• MK: I haven’t tried to rule them out.
• JWL: The select="'.'" in the expansion, what does that mean?
• MK: It’s going to generate a literal “.”.
  • … I’ve used xsl:element only very, very rarely.
• WP: This could be interesting.

Proposal: accept this PR

Accepted.

See PR #2283.

• MK: This is an attempt to bring the spec into align with common practice.
  • … In practice, people (including Saxon) use extension attributes to do anything where it’s useful to vary the processor.
  • … Tracing and debugging, that are entirely conformant, and other things like saying that the collection function is non-stable, that are not.
• MK: This proposal slightly changes the rules to say that it’s okay to change the behavior if you have good reason, for example, security.
• MK: The PR also brings extension attributes more in line with extension functions and elements.

MK reviews the prose of the PR.

• JWL: I can well understand these changes.

Proposal: accept this PR.

Accepted.