QT4 CG Meeting 130 Minutes 2025-07-22

Regrets: DB, BTW.

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

This meeting is planned for 22 July 2025. The following meeting is scheduled for 29 July 2025.

The CG will not meet 5 August. Does the CG wish to take a longer “summer holiday”?

The CG will take a short recess in late August. We will not meet on 26 August, 2 September, or 9 September.

(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
• [X] QT4CG-112-01: JLO to propose a concrete example that uses “.” in a ~%method~s.
  • Overtaken by PR #2108: QT4CG-123-01 Add example of library module using methods
• [ ] 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
• [X] QT4CG-123-01: MK to do the set example in XQuery.
• [ ] QT4CG-127-01: NW to diagram the JTree representing arbitrary XDM content.
• [X] QT4CG-128-01: CG to consider using “standard” or some other term instead of “regular” in the file: module.
• [X] QT4CG-128-02: CG to investigate what to say about permissions.
• [ ] QT4CG-128-03: NW to compare the file: module against the equivalent XProc 3.1 steps
• [X] QT4CG-129-01: MK to fix the remaining prose references to MapKeyExpr and MapValueExpr

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

MK introduces the PR.

• MK: It makes the argument optional and defaults it to “.”
  • … The usual error conditions apply.
  • … This brings them all in line with things like name() and local-name() on nodes.
• JLO: Do we have examples for those?
• MK: Yes, I’ve modified some of the existing examples to use it.

Proposal: accept this PR.

Accepted.

See PR #2110

• MK: This is a purely editorial change.
  • … In an absolute path expression, you don’t get implicit conversion of the context item to a JNode
  • … I’ve tried to keep implicit conversions to a JNode to a minimum.
• JWL: There’s a typo there “itemss”
• MK: 4.6.4 Steps has more discussion of when jnode conversions are performed automatically.

MK moves to the F&O spec.

• MK: More discussion of implicit conversion to JNodes.
• JLO: I would like to discuss if would if it would be better to do an implicit cast in the case of absolute path expressions.
• MK: The main reason I didn’t was that it would cause a surprise. If you think you’re deep within a tree of maps and arrays, you imagine that “/” is going to take you to the top, but it isn’t.
  • … Instead, you’ll get a root node for the subtree, which would not be what’s expected.
• MK: If you start with a map, it doesn’t have a parent, so it can’t navigate upwards.

Some discussion of how “/” is evaluated. (See 4.6.1, Absolute Path Expressions, in XQuery)

• CG: Maybe we should change the type error to a specific error code then we could explain to the user why it doesn’t make sense to use the “/”
  • … I can understand why it doesn’t make sense.
• MK: It occurred to me that we could forbid the leading “/” even if the context was a map or array.
  • … An expression starting with “/” would then always be an XNode.
• NW: That makes sense to me.
• JLO: I’m still trying to process the information about “/”. I have something in my context item; it must be in an XQuery main module.
• MK: Consider a/b/c/d[//x/y='2']. That selects “d” in the curren tree if the document that contains “d” also contains an x/y=2
  • … With JNodes, that “//” would take you to the root of the tree.
  • … But consider ?a?b?c[//x=2]. Here “c” might be a map, if that leading slash implicitly created a JNode, that would be JNode around the “c” map, it wouldn’t navigate up because there are no parent pointers to follow.

Some discussion of what the spec currently says.

• JK: Would there be a similar kind of error condition of the user used root()?

Some discussion of the distinctions between the lookup operator and navigation upward.

• MK: You can only navigate upwards if you navigate down with JNodes so that there are pointers to follow.
• CG: Examples

{'a': 1 }/a[/]  … ✓
{ 'a': 1 }?a[/]  … ↯
{ 'a': 1 }[/]  … ↯

• JK: I think we need more explanation here.
• WP: Why wouldn’t we always use slashes?
• MK: Partly, it’s historic, but it’s also very simple if you’re just doing a single-level lookup in a map.
• CG: I think there are many use cases where you don’t want to traverse, you just want to lookup.
• JK: I think the main thing we need to be reminded of is that “?” is breaking.

MK reviews what we current say about the lookup operator.

Proposal: accept this PR.

Accepted.

See PR #2111

• MK: This is the other half of it. Where do we call jnode-content implicitly?
• MK: In XQuery…
  • … Arrays and maps are coerced in FLOWR expressions.
  • … In an expression that must return a map, we allow it to be JNode.
  • … For filter expressions for maps and arrays, we allow you to supply a JNode.
• MK: In F&O…
  • … The coercion rules apply to JNodes where maps or arrays are expected.
  • … More examples under fn:jnode-content.
  • … But not for EBV or for functions like count or deep equal that accept arbitrary sequences.
• CG: It looks good. I think this PR should reference 2104 instead of 2095.
• JLO: Should we raise an error if you try to put a JNode in JNode?
• MK: I think that’s paternalism. Like forbidding multiplying by zero because it’s useless.
• CG: There’s an existing issue on that discussion; #2086.
  • … I think there’s also a question of performance. Checking for errors in a large structure could be expensive.
  • … I’m not sure how to forbid it easily.
• JWL: Do we have an “instance of” JNode test?
• MK: Yes.

Proposal: accept this PR.

Accepted.

See PR #2071

• MK: I’ve been doing some work on it, but it’s not ready to present yet.

Not ready for discussion.

• MK: The more I do examples of it, the more I find a need for the callback functions that do the local updates to create nodes.
  • … Doing a deep update in XPath really needs functions that create nodes in XPath.
  • … Do we want to bite that bullet?
• CG: I think it would be easy to create them in XQuery or XSLT contexts.
  • … It might be harder to do in a pure XPath case.
• JK: I’d love to have them. How much work would it be?
• MK: I don’t think it’s actually that excessive. The complications come with all the options for namespace inheritance and that sort of stuff.
• JLO: We explored this before, didn’t we.
• MK: Yes, but it was only a sketch, not a full proposal.
• JLO: I’d like to see it.
• WP: I’m with JK. Is this a clean subset of XQuery or what are we talking about?
• MK: I’d do it with functions rather than syntax.
• CG: Could we use the existing text(), element() etc. keywords as functions to make nodes?
• RD: As far as I’m aware, yes. The current tests don’t occur in a normal expression.
  • The other places where we have the names are text { }.
• MK: We’d have to refine the rules about reserved function names.
• RD: Do we have to?
• MK: Yes.

CG offers <a/>/text() vs <a/>/text('text') as an example.

See PR #2037

• MK: I haven’t tackled the big issues with streamability, just knocking off bugs as I find them.
  • … This is saying that the special rule of multiple consumable operands does not apply if duplicate keys are permitted.
  • … Just because that makes it a bit more difficult.
• JLO: Can xsl:map contain duplicate keys?
• MK: No, the result can’t, but you can define an action for what you do with duplicate keys.

Some discussion of why it’s harder to deal with duplicate keys.

• JWL: It’s highly unlikely anyone would try it, unless you were writing tests!

Proposal: accept this PR.

Accepted.

See PR #2019

Not ready yet.