QT4 CG Meeting 136 Minutes 2025-09-30

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

No regrets heard.

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

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

• JK introduces the issue with an example.

The example uses annotations that overlap other structures in the markup. Another example is quotation detection. Another example is a multidimensional plot of items. Another is an example of grouping polygons that overlap or touch.

• JK: The polygon example is similar to a problem in OCR for identifying paragraphs.

JK turns to the text of the PR.

• JK summarizes “split-when” and “merge-when”.
• JK: Might not be used very often, but when it’s needed it will be very appreciated.
• MK: Is the result independent of the order in which you compare groups?
• JK: I tried that, but the comparitors might be asymmetric. (See the last example with animals.)
• MK: Do you always have to do n² comparisons?
• JK: No, if you can work out that the comparitors are symmetric then the order doesn’t matter.
• JLO: Very interesting. You have a mixture of the different cases and the examples aren’t presented like other examples. That would be a nice change.
• JK: I did two larger examples, the others were more compact.
• JLO: Should we add a comment about optimization?
• MK: That’s always true, but we could add hints if we think they’re useful.
• JWL: Why don’t we use functions here, rather than expressions? Then we wouldn’t end up with variables that have special names.
  • … Is there a reason for this?
• MK: I’ve had the same question with other things we’ve added. Generally, the answer is that making it an expression or a pattern makes simple cases simpler.
• JK: If we find an alternative that uses functions, we could do that.
• JWL: In grouping we use reserved functions: `current-group()`, `current-grouping-key()`
• JLO: This only effects XSLT, right?
• JK: Yes.
• MK: The more exotic features of the languages are sort of unevenly distributed across XQuery and XSLT. Why do we do advanced windowing in XQuery and advanced grouping in XSLT? I’m not sure we’d have a good answer.
• JK: I’d love to see this in XQuery.

Proposal: accept this PR.

Accepted.

See PR #2211.

• NW: Did we get any feedback from RD on this one?
• MK: I don’t think so.
• NW: Shall we wait?
• MK: I’m pretty confident that we want to go ahead. I think the option would make more sense for implementors than users. I don’t think there’s any benefit to users in having a choice. I think the intuitive way is not compatible with the DOM but the HTML parsers do it by that way by default.
• JLO: I agree.

Proposal: accept this PR.

Accepted.

See PR #2209.

MK introduces the PR.

• MK: Remember that treat as is a hangover from strong, static typing. The way it’s described has vestiges of that.
• MK: The main substantive change here is that if treat as fails it’s a type error not a dynamic error.
  • … Most of the changes are just changing dynamic error to type error.
  • … It keeps the error code in case people are catching it.
  • … The wording changes bring the description into line with the rest of the spec prose.
• JWL: Can this be raised at runtime and at compile time?
• MK: Yes. It’s a type error so you can statically report that 3 treat as xs:string is an error

Proposal: accept this PR.

Accepted.

See PR #2205.

• MK introduces the PR. What CG had done in the interest of consistency was to allow all the parse functions to accept binary input in additionto text.
  • … I think for CSV and JSON that’s inappropriate and possibly misleading.
  • … It makes sense for HTML and XML because the encoding can be in the file.
  • … But for CSV and JSON there are no such rules in the specifications. Decoding is completely orthogonal to the parsing.
  • … So I don’t think they need to be combined. Except, perhaps, to make the interfaces similar to other functions.
  • … We might want a way to decode a string, but that’s a separate issue.
  • … And if you start with binary input, the binary module gives you a way to decode them data.
• CG: I think it would be helpful to allow both string and binary. If you have binary data, the encoding or byte order mark might be in the data. We don’t have any way to infer an encoding from data. You can do it from data, with unparsed-text(), but that might mean writing the data to disk in order to infer the encoding.
  • … I think it would be helpful to have for CSV and JSON data as well.
  • … For users who don’t care about the specifics of the specifications, I think it can be helpful to have a uniform API to the functions.
• MK: If we don’t have a function to decode binary based on inferring the encoding, shouldn’t we add one?
• CG: Yes. I’ve opened a proposal to extend decode-string to be able to infer the encoding.
  • … The functions csv-doc and json-doc, would you expect them to infer the encoding?
• MK: I think the answer there is, if nothing is supplied, I would expect it. It comes in HTTP headers, for example.
• CG: So I could imagine that someone might want to swap cvs-doc and parse-csv because the data is already available. So it would be helpful if the interface was the same. That would be a consistency issue.
• MK: This is about the parse functions not the doc functions.
  • … I think it’s at the point where you’re dealing with the external resource where you want to decode.
• JLO: I’m uncomfortable dropping it. I’d like to not have the extra step necessary. Now that I hear that there might be some usefulness in interpreting the BOM, I’m torn.
• JK: CG, you mentioned another PR for decode string. Where is that?
• CG presents issue #2217 where the proposal exists.
• JK: Would that be used to extend parse functions to do binary.
• CG: That’s what I did by putting binary into all the parse functions.
• MK: JSON and CSV start with characters, so you don’t need binary.
• JWL: Is it a great deal of implementation work?
• MK: It’s more about writing tests!
• CG: We might also want to consider adding an encoding option.
• MK: That’s also a problem, once you add complexity, it starts to multiply.
  • … In fact, that’s how this started. We have parse-csv that accepts binary but we have no way of specifying the encoding.
• WP: I’m a bit out of my depth; but in my experience the problem goes beyond what we can do. The specs say one thing and the world does something else.
  • … I think making it transparent and usable on the edges is good.
  • … If that’s the case, I’d be in favor of allowing binary.
• JK: I think before deciding on the fate of this, we should look at decode string.

There isn’t consensus to make this change; we’ll leave the status quo.