QT4 CG Meeting 139 Minutes 2025-10-21

• [X] 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)
• [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 28 October 2025.

Heads up: daylight saving time ends in the UK and Europe on 26 October 2025. It ends in the United States on 2 November 2025. Our meetings are scheduled on European civil time, consequently, our meeting of 28 October 2025 will occur one hour later in the United States at 12:00EDT.

JK gives regrets.

None

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

CG introduces the PR.

• CG: There are some clarifications.
  • … I added a discussion of how to determine the encoding.
  • … The old rules weren’t complete.
• JLO: It sounds reasonable. Is it incompatible with the current version?
• CG: It’s compatible.
• NW: I’m surprised that the encoding specified isn’t unconditionally accepted
• CG: You do. The first four rules only apply if the encoding is absent.
• NW: blush

Some discussion of server encodings.

• WP: Are the different very often?
• NW: I don’t think so, most of the world is using Unicode now.
• RD: According to the WHATWG encoding spec, all the old encodings (Big5, ShiftJIS, etc) are marked as legacy. They’ve pretty much standardized on UTF-8 but also supporting UTF-16. That’s typically supported by all the major web browsers. See https://encoding.spec.whatwg.org
• MK: Does the new text make it clear whether the BOM is dropped or included.
• CG: It says “can be consumed”.
• MK: That says “can”, I don’t think that’s clear. There was a final sentence that said the BOM was discarded.
• CG: That’s because the BOM is only discarded in the first three cases.
• NW: I think an explicit statement that if a UTF encoding is determined and a BOM is detected, it is discard.

Proposal: accept this PR.

Accepted.

NW will merge it after CG adds the clarification requested.

See PR #2248

MK introduces the changes proposed for the Data Model.

• MK: It adds 7.3 Base URI that explains that the base URI can change, can be absent, and that in practice you can’t rely on the value conforming to XML Base.
  • … You may accept a DOM or some other tree model that was constructed with a value that wasn’t validated.
  • … Pragmatically, we acknowledge a third state: present but invalid.
• MK: That sets the ground work for saying that anything that relies on the base URI may raise a dynamic error in this case.
• CG: Thanks. I wondered what would happen if fn:base-uri is called or if you have a direct constructor?
• MK: If you’ve got an invalid base URI, it’s best to say that all bets are off.
• CG: So it’s implementation dependent in practice.

Proposal: accept this PR.

Accepted.

See PR #2223

• CG: I asked to have these options added, but on further exploration, there are a lot of other limits in the JDK. So we would need lots of additional options.
  • … We also discussed the possibility of specifying different trust levels, but we dropped that because it was limited to doc and parse-xml. It should be more global.
• CG: So if we’re going to do that, it makes sense to drop these options.
• RD: So are we thinking about something more like the number-format options?
  • … In XQuery you can use declare-decimal-format and declare a name.
  • … We could have a declare-security-options …
• MK: That’s a leap.
• CG: That could be one way. Some use cases I have in mind are that users can write their own query and we need to decide before that step that we need to know what the user should be able to do. Those could be prefixes to the query.
  • … There are use cases where option declarations would make sense.
• JLO: We both have global options; they are not in the spec, but we don’t need to have them in the spec unless you want to override them.
• CG: One difficult question is which options will be sensible at all? It depends a lot on the implementation: Java, JavaScript, C, etc. What can the implementor actually do?
• MK: I’ve got mixed views because I agree these options are inadequate. I’m slightly reluctant to get rid of the only thing we’ve got. The area is important to people and we do get questions about them. My instinct is to accept this proposal but recognize that we have to do something.
• JWL: If we think about this notion of doing a declaration, recall that the changes you can make at that level can only be more strict than the security policy above the query.
• WP: I think MK put his finger on the problem. As I see it, it’s a question of how the control interface can be exposed to the user in a useful way. But if it raises more questions than it answers, then it might be better to have something simple that’s easier to test.
• RD: There are different levels. With Java, there are various flags you can pass to the parser. In Python, there are various libraries and things with different options and things like parser hardening. It’s difficult to get a set of options that are platform/language agnostic.
  • … Then there’s the point about where do you pass them. If you want to be really secure, you’d pass them as command line options.
  • … Do we want to have the ability to report different exceptions have failed to parse entities.
• NW: I think there’s another dimension: does the user writing the query or stylesheet trust the user? Sometimes I want to impose the constraints at the point of the parse.
• JLO: There are different levels, like NW said, I might want to run a parser or something with limited options.
• CG: Look at #2034 that we eventually decided to close.
• JWL: There’s another PR talking about these levels; putting the possibility of individually restricting on calls. A very good example might be that I’ve got an XSLT stylesheet that uses xsl:evaluate; I need to do that, but I might want to limit specific calls to xsl:evaluate to limit file access, for example.
• MK: Is it worth looking at the #2213.

CG displays PR #2213.

• MK: This attempts to provide a summary of the ways that you can access external resources.
  • … Then it adds a trust level to the context. How much do you trust a particular piece of code?
  • … You don’t really want to say allow external entities on one document and not another, what you want to say is that I trust the person requesting these documents.
  • … The main level where you want to change the trust level is when you invoke new code: the environment, fn:transform, xsl:evaluate, etc.
  • … I’ve tried to limit it to three levels.
• JLO: I think this goes in a good direction. The level names are somewhat arbitrary, I’d prefer things like, “no external access”, or other labels that tell me more about the limitations.
• CG: What I can add is that I like the idea to have a global way to decide what to do. The challenge is to line this up with implementations. In BaseX, we have lots of levels of access to databases, admin permissions, etc. But it’s all BaseX specific. It’s not going to be possible to make this relevant for Saxon, for example. And how would we bring these levels together with our own security management.
• JK: I think from this conversation, what I’m getting is that we need this not just statically but also at runtime. What I want as a user is to make that interface pretty much the same in both case.

Proposal: accept #2223.

Accepted.

See PR #2205

• CG: When we discussed this PR last time, we thought it might be best to wait until we’ve revised decode-string.
• NW: Fair point, let’s wait until we’ve done that.

See PR #2251

• MK: I resisted for a while, but I’ve been persuaded.
• MK: What I’ve tried to do is make xsl:text and xsl:value-of as similar as possible.
  • … There are a fair few incidental mentions that are no longer relevant.
  • … A new section, Creating Text Nodes, introduces both xsl:text and xsl:value-of
  • … The only real difference is that whitespace text nodes are preserved in xsl:text
  • … (There’s also a difference in 1.0 backwards compatibility mode)
  • … Most of the rest of the text is from xsl:value-of
• JWL: Is there any merit in trying to make xsl:attribute similar as well?
• MK: Where they come together is in creating simple content.
• JK: I really like this. The biggest take away is that xsl:value-of is essentially deprecated.
• MK: We haven’t explicitly deprecated it, but I agree I wouldn’t recommend it anymore.
• WP: I also like the proposal. The one thing I’d throw in there is that in the first example we wouldn’t use three instructions like that in a row.

Some discussion of the distinctions with respect to whitespace.

• JLO: Does it make sense to have a separator on comments?
• MK: I don’t see a strong need to change comments just in the interest of orthogonality.

Proposal: Accept this PR.

Accepted.