QT4 CG Meeting 176 Minutes 2026-08-18

JLO gives regrets.

• [X] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:06-]
• [X] Michael Kay (MK)
• [ ] 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 25 August.

DB gives regrets.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-167-03: NW to make a PR for #2482, fallback on bin:decode-string
• [ ] QT4CG-167-05: MK to write a proposal to change #2393 so the functions return JNodes
• [ ] 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-174-01: MK to make an issue or otherwise address CG’s comments on #2734.

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

• MK: The proposal is to mark the function as non-deterministic if the debug is true. But determinism is a property of the function, not a runtime choice. This is fuzzing things a bit.
  • … Implementations can still do it, but if we want to do this, we should do it more broadly.
• CG: I think we already have to make this change because fn:doc has similar properties.
• MK: Yep.
• CG: I’ve seen this in real examples where a static compilation overrode the users debug setting.
• MK: Do we leave this to implementors or do we try to formalize it? And if we formalize it properly.
• WP: Is this only about debug?
• CG: Yes.
• WP: I think MK is correct, those issues can be called out as points for implementors to work.
  • … If we do it, we have to do it right.
• CG: That’s what I think.

NW oberves we don’t have consensus.

• MK: I think a note suggesting that implementors look at this carefully.

See PR #2841

• MK: Second thoughts on this as a result of discussion.
  • … My initial feeling was that decode is a transitive verb and what you’re decoding is a URI.
  • … Bug CG observed that the URI spec says you should parse a URI and then decode it’s parts.
  • … Do we really need decode-uri, given that we have parse-uri?
• MK: After all that discussion, I think my instinct is to withdraw the PR.
• CG: We introduce this function three years ago and it’s widely used.
  • … When we introduced parse-uri, people were asking for decoding
  • … I don’t think it’s a problem decoding full URIs.

Proposal: close this PR without action.

Accepted.

See PR #2842

• MK: There were some editorial comments that I’ve fixed shortly before the meeting.
• MK: The PR is about consistence between F&O and XSLT.
• MK: In F&O:
  • … The example expresses what we’re doing. the group is now expressed as a record that contains the string value, the position of the group, the group number and the group name.
  • … The number is redundant, but it’s the key. But you will still have them available.
  • … The PR only effects the definition of ~fn:matching-segment-record.
  • … Groups now contains a sequence of capture group records.
• MK: In XSLT:
  • … Regex groups now uses the same captured group record and refers to it with a cross-spec link.
• NW: I don’t much like nr; we haven’t generally used cryptic abbreviations.
• MK: I called it nr because that appears as an attribute name as an output of the analyze string function.
• NW: Okay, I failed to notice at the time.

Proposal: accept the PR

Accepted.

See PR #2840

• MK: Let’s take that along with the one on array and array-members.

See PR #2839

• MK: The motivation for this is that I was working with the XSD validator function. That gives you a function that validates a single node. It suggests that you can get information about the location of validation errors.
  • … But we have no way of asking when parsing the tree that they should retain that information.
  • … I don’t think implementations in general want to maintain location information on every parsed document.
  • … It’s typically a little bit expensive.
• MK: I’ve proposed that the doc and parse-xml functions should have options to retain it.
  • … I’ve added properties to the data model
  • … And a function to retreive that information, if it’s available.
• MK: In the Data Model:
  • … We have a location accessor that returns public and system identifiers and line and column.
  • … The actual values returned may differ.
  • … It’s not interoperable across implementations.
• MK: In F&O:
  • … There’s a new fn:location function that returns a location record, with similar caveats.
  • … And there’s a new fn:location-record
• MK: I’ve defined it as positiveInteger, we’re a little inconsistent about that.
  • … But this forbids zero.
• MK: There was a comment that copying the node shouldn’t copy it’s location. I’ve added that.
• JWL: Is there any runtime mechanism that would allow you to tell if you were going to get location?
• MK: No, you try and get an empty sequence back.
• JK: Having had to write one of these function myself, I’m pleased to see it added.
  • … I wonder if it’s worth noting that the column count might be effected by entities
  • … Is it worth providing an implementation-defined field that attempts to identify the parser?
• NW: I don’t think that’s practical, the APIs don’t really reveal it.
• MK: Yes, entities cause all sorts of complexity. Entities don’t reveal things like where the attributes are.
  • … But we can’t legislate here because we don’t know what the parser is going to do.
• CG: I think many people will be grateful for it.
  • … I think it would be helpful to raise an error if location information is requested and it isn’t available.
• MK: The trouble is that it’s only partially available: for elements but not attributes, lines but not columns, etc.
• MK: With respect to making it an error, I think that’s difficult.
• CG: With regard to positive integer, I’d rather see integer there. It may be easier for implementors to optimize this.

Proposal: accept the PR

Accepted.

See PR #2834

• MK: This one is purely editorial. Well, except in the sense that it defines some edge cases.
• MK: It’s entirely in the serialization spec.
• MK: First, we update the item-separator property.
  • … We note that it’s treated like any other character, they aren’t treated specially.
  • … So if the item separator is \n and the line ending is \r\n, then you’ll get \r\n.
• MK: Line ending adjustment is now introduced as a separate phase.
  • … That makes it much clearer when you do the adjustments and what is effected.
• MK: There’s a note that tries to be a bit more precise about the meaning of indent-unit.
• MK: In indent-attributes, we add a note that we aren’t going to be entirely prescriptive.
• MK: For JSON output, we say that we aren’t really going to tell you how to use indent-unit. There’s a lot of variation.
  • … There’s a note that points out that line-ending only applies to inserted ones. All the others will be \n already.

Proposal: accept the PR

Accepted.

See PR #2833

• CG: This one is editorial. The issue was that various record types had not been named yet.
  • … For example, fn:divide-decimals.
• CG: We also have parameter types as well.
• CG: The biggest change is fn:sort-by, mostly the signature becomes more readable.
• CG: The other changes are trivial.
• CG: fn:divide-decimals and a few other functions now return record types.
• MK: There’s an editorial comment that we really ought to find a way to do better linking.

ACTION: NW to see about improving the linking for record types.

Proposal: accept the PR

Accepted.

See PR #2832

• CG: The proposal is to change the options for fn:doc and fn:parse-xml to be enums.
• CG: I introduced the same enum, but as JK noted it’s confusing.
  • conditional makes no sense for parse-xml.
• CG: I’m torn. Maybe we could drop conditional and only offer all and none.
• MK: My instinct is to make the parse-xml function and doc symmetric so that it works for both.
  • … It just seems more othogonal that way.
• CG: Would it be sufficient to adopt the descriptions as is?
• MK: Probably the only thing is that for backwards compatibility, the default migth be different in the two case.

ACTION: MK to refine the strip-space option so that it takes account of historical defaults.

Proposal: accept the PR

Accepted.

See PR #2824

• CG: This one has a long history.

It’s related to generator functions and we will have to come back to those proposals soon.

• CG: There are new examples that help to explain why it’s useful.
  • … The interesting thing is that scan can be composed with take-while.
  • … So it’s easier to use than fold-left or fold-right.
• CG: Scan is iterative by nature so you can more easily optimize it.
  • … We only need the left variant. It cannot be optimized the same way in fold-right.
• JWL: Can you go back to the usr/local/bin example.
  • … So the result should be a sequence of arrays, shouldn’t it?
• CG: Because of the ! ?*, it will be a sequence.
• JWL: Right. I didn’t spot that. Might be worth a note.
• CG: In the beginning I was against introducing the arrays, but DN convinced me it was a good idea.
• MK: Following on from John’s comment, does the ! operator in those examples do anything?
• CG: Mmmm, maybe it would work without.

Proposal: accept the PR

Accepted.

See PR #2822

• MK: This is actually a bug in the 3.1 specification. It arose as the result of a Saxon bug report.
• MK: Prefix normalization effects the XHTML output method. It’s a consequence of the fact that serialization drops the namespace for MathML and SVG.
• MK: The rules talk about how that’s done. You drop the prefix and rename the node and drop the namespace nodes.
  • … But it said you drop the namespace nodes including the default namespace, that results in xmlns="" in the output.
• MK: I’ve dropped the XSLT example because it didn’t work.
• MK: The substantive change is that it now says it drops any namespace node that has a prefix.

Proposal: accept the PR

Accepted.

See PR #2805

• CG: We’ve introduced function identity a while ago. We have a function fn:function-identity that gives you a string.
• CG: The problem is that if you keep function identity, you have to define a lot of functions as nondeterminstics. Basically, all the functions that return functions.
• CG: Do we really need this? It’s very implementation defined, but in most cases it’ll be surprising.
• CG: We’re left with the fn:deep-equal function. It can currently compare functions inside maps and arrays.
  • … We could always return true or false, but I think it would be better to raise an error.
  • … But we could add an option to ignore function items.
• CG: It will have effects on the definition of jtree because there’s a lot of discussion about how functions change the identities.
• CG: I think the result will be simpler.
• MK: The case I care about is fn:deep-equal. In particular, deep equal of records an in particular records that contain methods.
  • … If you have a record that has a has a function as the default value, then two calls to its constructor should be deep-equal if they have the same data fields.
• MK: That only works if you have some kind of concept of “same method” which means that “same method” means something.
• MK: I’d like to de-emphasize function identity in other places, I still think we need to handle that case.
• CG: I think the main challenge will be to define what an optimizer is allowed to do and not allowed to do.
  • … (There’s an example in the issue that shows some consequences of optimizer rewriting.)
• WP: Identity and equality aren’t problems we’re going to solve.

More discussion required.