QT4 CG Meeting 126 Minutes 2025-06-24

Regrets: BTW, DB, MK

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

JWL gives regrets for 1 and 8 July.

(Items marked [X] are believed to have been closed via email before this agenda was posted.)

• [ ] QT4CG-082-02: DN to work with NW to come to agreement on the fn:ranks proposal
• [ ] QT4CG-112-01: JLO to propose a concrete example that uses “.” in a ~%method~s.
• [ ] 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-123-01: MK to do the set example in XQuery.

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

CG has incorporated most of the feedback from last week.

• CG: One observation was that we could use unparsed-binary instead of unparsed-text.
  • … Also, we wanted to have some comments on parsing XML.
  • … Added a reference to the fn:doc function which has some information about encodings.

Proposal: accept this PR.

Accepted.

See PR #2049

CG displays the document for us.

• NW: this PR changes a half-dozen or so functions to allow the empty sequence.
• JLO: Generally, I think this fine. I would still like to know the justification.

Some discussion of the consequence of allowing the context value to be a sequence.

• JWL: In all of these cases, if the context value is an empty sequence, the functions return an empty sequence.

That’s correct.

• WP: When you call it with no argument, you’re still going to default with the current context, but that might now be an empty sequence.
• JWL: The point is that it’s still . but that can now be an empty sequence. Previously, we expected . to be a singleton.

Observe that the test is for node()?, so you can’t pass a sequence of more than one item.

Proposal: accept this PR.

Accepted.

See PR #2015

A quick review of the PR.

• RD: This is only apply to maps and arrays?

Some discussion of what the result is if the result is a string, instead of a map or array.

(Some fumbling with the result of the diff.)

• RDL: Does this need to be noted as a breaking change? If a string is returned, you won’t get a document node?
• NW: I think that’s only true if you use xsl:select.
• JWL: There’s a distinction here between xsl:sequence select=… and xsl:select.
  • … The way to think of it is that xsl:select is letting you use a child instead of an attribute so that you avoid normalization.

Proposal: accept this PR.

Accepted.

• Issue 2059: Literal QNames: Adaptive serialization
• Issue 2058: Literal QNames continued
• Issue 2056: Implicit Whitespace in MarkedNCName and QNameLiteral

CG created PRs and the group agreed to discuss them today.

• CG: The adative serialization method is mostly for debugging, so we can make that simpler.

CG reviews PR #2060.

• JLO: In the example that you showed, even with an empty namespace there was a #Q{}a
• CG: Yes, that was my first idea, but we can omit the braces in that case.
• RD: Can we look at the text without the diff?
• CG: Yes.
• JWL: Do we have anywhere else where we’re likely to get a problem with # followed by a letter?
  • … We have Q{} or # just followed by a string. What if the name starts with a Q?
• RD: If it’s not followed by a curly brace then it won’t be a QName.
• JLO: So it’s easy to tell.
• JWL: If this is really for debugging and you aren’t going to parse it, I’m not sure if using # without the curly braces is actually less confusing.
• JLO: I’m using adaptive serialization a lot, the distinction is between # and “#”.
  • … There’s no other way to get a # without quotes, so I don’t think there’s a problem.

Proposal: accept this PR.

Accepted.

• CG: Next we have annotations.

CG reviews PR #2061.

• CG: This is XQuery only because it’s annotations; this could be useful for RESTXQ. It wouldn’t require parsing strings, you could just supply literals.
• RD: Another example of this is that you could have a throws annotation that specifies the error literal directly as a QName.
• JLO: I’m completely in favor, but why don’t we allow maps and array literals?
• NW: That sounds like a separate question.
• CG: I think the main reason is because its easier to have things that can be statically parsed.
  • We avoid using unary here, for example, because we don’t want to allow more expressions.

Proposal: accept this PR.

Accepted.

• CG: Gunther observed that whitespace is not allowed between # and the name.
  • … It has no effect on pragmas, because they require a whitespace.

CG reviews PR #2064.

(Only the grammar has changed, so there are no diffs.)

• CG: The change is just removing whitespace-spec in the production.
• JWL: Has anyone ever actually seen anyone use spaces after $.
• JLO: It’d be interesting to know how many parsers fail at this point.
• RD: My IntelliJ plugin has loads of tests for this sort of thing.

Proposal: accept this PR.

Accepted.

The group agrees to look at a few more PRs.

See PR #2065

• CG: This is mostly editorial. In map:build, multiple keys is mostly a special case.
  • … This PR also removes the ability for simplicity.
• RD: Not related to this, but it might be easier to read if the elements in the sygnature table are allowed at the top.
• NW: Yes, make an issue and assign it to me, please.
• JWL: We have decided not to support any idea of a sequence value for a key. Is that right?
• CG: That’s right.
• JLO: The function that produces the key is still xs:anyAtomicType*
• CG: The function isn’t changing, just removing the plural.

Some discussion of what happens when the key is an empty sequence; no entry is created.

• JLO: Are there any examples of multiple keys?
• CG: Apparently not.

ACTION QT4CG-126-01: JLO to add an example where the map:build key function returns multiple keys.

Proposal: accept this PR.

Accepted.

See PR #2062

• CG: The fn:sort-by function allowed you to omit the second argument. It looks a bit lost to have sort by with out any sort key. My suggestion is to make it manditory, even if it can be the empty sequence.
• NW: Seems reasonable to me.

Proposal: accept this PR.

Accepted.

CG introduces the issue.

• CG: I haven’t checked all the details yet, so this is just a suggestion.
• JWL: This is what I was asking MK about with JNodes.
  • … I asked could you do a similar thing on normal nodes.
  • … He implied that this was a lot more problematic, I’d like to hear his opinion.
  • … I like it, it would be an easy dynamic mechanism for putting them in expressions.
• CG: I think we about $node/$name and that definitely won’t work.
  • … But I think adding element() would work.
• JLO: I didn’t know that you can do $node/$name.

Some discussion of what that currently means!

• JK: I’d like some feedback on my #2051 if anyone can take a look.