QT4 CG Meeting 187 Minutes 2026-11-03

Regrets: DB, BTW, JWL.

• [ ] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [x:05-]
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [ ] John Lumley (JWL)
• [X] Alan Painter (AP)
• [X] Wendell Piez (WP)
• [ ] 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 10 November.

NW, BTW, WP, JLO give regrets

Per AOB, JK to chair.

WP gives regrets for 17 November.

NW also gives tentative regrets for 17 November.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-167-07: NW to review tests for interpolated strings with edge cases in mind
• [ ] QT4CG-170-01: RD to draft a proposal that attempts to address the lexical issues differently.
• [ ] QT4CG-177-01: NW to put the progress graphs back in the minutes.
• [ ] QT4CG-182-01: NW to review CG’s diff script

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 #3031
• MK: This is a short proposal. It probably needs more motivation. It’s motivated by matching JSON in XSLT. It’s much easier to write match templates for records.
  • … The detail is straightforward. It adds an option to fn:parse-json and fn:json-doc that lists record type names.
  • … (Note that this is the first use of record type names at runtime.)
  • … If you match a record type that can be coerced to a record type…you do so!
  • … CG observes that we need to be explicit about the fact that it matches bottom-up.

MK muses that this probably needs a bit more work.

• AP: Do we have to be specific that this is about labeled record types.
• MK: Yes, okay.
• JLO: What happens if none of the record types match?
• MK: Then you just get a map.
• JLO: I can’t restrict it to only matching types?
• MK: No. It’s not doing validation. I suppose it could be extended in that way.
• RD: I can see this being useful. Specifically, when processing JSON data with a schema.
  • … In those cases, it’s generally defined at the top level. I wonder if that case is supported.
  • … You could say that the top-level must conform to this record type.
• MK: Oh, yes, that’s interesting. That’s a case for top-down processing.
  • … I think you’d get that if you just define a record type for the top level, then that will be coercable even if the things inside it are unstructured maps.
• RD: You would but you can’t enforce that.
• MK: I’ve steered clear of supporting JSON schema here.
• RD: But you could theoretically create a JSON schema-style binding. Adapt the JSON schema into a collection of records.
• NW: Can’t you just assert that the result had the right type?

General agreement that you can.

• WP: I like this a lot. I think the validation question will come up again. At least, they’re going to have to be ready to think about it. It isn’t going to be invisible all the time.
  • … I think it would be worth explaining what failure looks like if you get the types wrong.
• CG: I agree. It’s a nicep proposal. I also thought about validation. If we can assure that the result will match the record, we could do some static lookups.
• JLO: For me, the proposal isn’t clear what happens if none of the types match.

ACTION QT4CG-187-01: MK to elaborate on the proposal in PR #3031

• See PR #3026
• CG: This one is very small and tries to justify what BaseX does at the moment.
  • … The default for recursive is false. I think it would be better if this was implementation defined.
  • … It’s fairly old and used a lot so it might be safer this way.
• JLO: I’m for it. I think we also do true by default.

Proposal: accept this PR.

Accepted.

• See PR #3016
• MK: Because we can’t encapsulate records, and have no data hiding of their contents. You can’t use O-O techniques to hide it.
  • … Instead we add a declarative integrity constraint that must always be true.

MK reviews the prose of the proposal.

• MK: “must evaluate to true” really means “its effective boolean value must be true.”
• MK: There are various places where we say that the integrity constraint must be satisfied: basically anything that can create a new instance of the record type.
• MK: I’m relying a bit on XForms experience. They have similar sorts of conditions for validations. It’s reasonably easy to pick apart an XPath expression to work out what checked.
• MK: I extended the atomic set example to exclude NaN by way of example.
• RD: Is it possible to support where clauses where you have a sequence of effective boolean values?
  • … Where all of them must be true.
• MK: Sure. You have the full power of XPath there.
• MK: It’s evaluated with the candidate item as the context item.

Some discussion of multiple predicates, multiple where clauses.

• MK: I decided chaining them together with and was the best solution.
• WP: In the XSLT equivalent, the where clause will be in an attribute.
  • … I think this is extremely powerful. It will be interesting to see JSON schema compiled to something like this.
• JLO: Interesting approach. Is it an error to write expressions that can never be true?
• MK: No, you can write where false(), you’ll just never be able to create the record.
• CG: When I first saw this, I was concerned that people could do all sorts of things in the where clause. I think it’s up to the user to use it reasonably.
  • … I found a few minor syntax errors.
  • … Should it be a ExprSingle?
• MK: Keeping it single leaves open the possibility of extensions in the future.
• RD: That goes back to my point about a list.
• MK: In XSLT, we’d want to make it a general expression because it’s within a single attribute.
• RD: Going to JLO’s point about having where false(), does that mean we can now define the “none” return type on fn:error as an empty record with a where false() clause?
• MK: It’s another way of having a type with no instances, but we already have ways to do that.
  • … We have xs:error which is a type with no instances.

Proposal: accept this PR.

Accepted.

MK to make the “effective boolean value” change and merge this PR after the meeting.

• See PR #2998
• MK: We have trusted and trusted external options on functions. I found when implementing them that the details weren’t spelled out clearly. This PR attempts to fill that gap.

MK walks through the revisions to 1.5.6 Function Security in F&O. The details come in the individual functions.

Some discussion of whether a security failure should be revealed in an error code.

• CG: In the comments, I had about 10 minor comments that I think should be added to the PR before it’s merged.
  • Early failure is currently not allowed. Maybe we could allow failure statically.
• MK: If the allow list is empty you can fail statically.
• JLO: I’m glad to see this work. I’m also all for denying any information. The ability to finger print servers would be a problem.
  • … I would like to propose that we add an annotation so that others can also say that this function is sensitive.
  • … The list should be extensible.
• MK: Yes. We don’t provide any features for users to write functions that are security sensitive except by calling one of these.
  • … Implementations are obviously going to have to extend it to cover their own extensibility mechanism.
• WP: What happens if you get a 404?
• MK: That sort of implies that the processor wasn’t restricted from attempting, but it got a failure when it tried.
• WP: I’d like to see a citation on security practice here. I’d like to draw this line very carefully; security is more a matter of practice than tooling.
  • … I appreciate the work here, it’s a difficult area to get right.
• JK: I think this is a great step forward. I was reading the section on the file function library and noticed that calling fn:function-lookup triggers this mode.
  • … If I have function lookup and I’m safe-guarding it with a boolean, will that trigger the warning?
• MK: I think I’d need to look at the detail.
• JK: I’ll often say “if this static is true then use this function otherwise use this other function”.
• MK: No, the sandboxing is something that happens at runtime, it happens if you try to invoke a function that’s not trusted.
  • … Yes, you can potentially have the same code and have it behave differently depending on the trusted settings.
• RD: I understand the reasons for making the error codes opaque, but I’m thinking about the cases where you’re implementing the XQuery code and you run it and it fails because the file doesn’t exist and you spend a day hunting for it only to find that it was a security issue. I wonder if there would be a way to toggle that.
• MK: I think that sort of diagnostic option has to be implementation-defined.
• WP: I think that implementations can help. An option to say that you’re being sandboxed would be very helpul.

MK to review CG’s comments. Discussion to continue.

• See PR #2986
• CG: The motivation was MK’s proposal to add the namespace axis to XQuery.
  • … I was reluctant, but it turns out not to be a big challenge.
• CG: The question is really should we have it in XQuery?
• MK: It was originally believed by XQuery implementors that it was too hard to implement efficiently.
  • … I think that’s been largely disproved.
• CG: XQuery Update doesn’t support the namespace axis, so that’s something that needs review.

Proposal: accept this PR.

Accepted.