QT4 CG Meeting 128 Minutes 2025-07-08

Regrets: DB, JWL, BTW

• [ ] 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)
• [ ] John Lumley (JWL)
• [ ] Dimitre Novatchev (DN)
• [X] Wendell Piez (WP)
• [X] 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 15 July 2025.

No regrets heard.

(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.
• [ ] QT4CG-127-01: NW to diagram the JTree representing arbitrary XDM content.

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

MK introduces the PR: it’s a branch on top of the JNodes branch.

• MK: It’s inspired by a remark from CG about not overloading the “?” operator. I went back and considered if we could use “/” now that there’s more symmetry in the axes.
  • All of the substantive changes are in path expressions.

MK walks through the revised prose.

• MK: I changed the structure of the grammar, but not the semantics. Forward and reverse steps are no longer a syntactic distinction.
• MK: There’s more change in the section on node tests.

Looking at the syntax first.

• MK: A SimpleNodeTest is now either a TypeTest or a Selector (KindTest has been generalized to TypeTest and NameTest has been generalized to Selector).

MK walks through the details of the grammar.

• MK: We split into selectors on XNodes and selectors on JNodes.
  • … There’s a new capability where as selector can take get(expr). You can dynamically compute the element names you want to select.
• MK: The complimentary text for JNodes is the same syntax but different semantics.
  • … The semantics of NCName now depend on the kind of expression you’re evaluating.
  • … Indexing into arrays is child::*[3] (or child::get(3)).

Moving on to type tests.

• MK: With sufficient contrivance, I think you can probably wrap a JNode in JNode. So it’s possible in theory that you’d want JNode().
• MK: In the abbreviated syntax, @ is retained but doesn’t apply to JNodes.
• MK: The other area of change is Lookup Expressions which I’ve trimmed back to basically what we had in 3.1. We don’t need to have two solutions to the same problem.
• JLO: I’m very pleased. I have some questions…what happens if I’m doing a path expression like child::code on a mixed sequence?
• MK: At the moment, there’s no rule that says the left hand side has to be homogeneous.
• JLO: So what will this return?

  (<code/>, map{“code”: 1})//child:code

• MK: That will select from both of them.
• JK: Satisfying and gratifying. In the JNode selector section, the examples assume that the JNodes are arrays or maps. What happens if they are entries?
• MK: There probably should be more examples of that. I think the rules cover it because they’re defined in terms of the children accessor.
• JK: It’s really going to throw people if it returns unexpected results.
• MK: In a sense, I want to focus on the core cases first.
• RD: I agree this all looks very good. The item type “instance of” expression for GNodes and JNodes should be lower case.
• MK: There’s a precedent in QName where we use upper-case.
• NW: I was going to make a similar comment.
• JLO: More generally, we have GNodes, XNodes, and JNodes and we have XTrees and JTrees, but do we have GTrees?
• MK: A tree either consists entirely of JNodes or entirely of XNodes. A GNode is an abstract concept; it’s always one or the other.
• JLO: We have document node in the absolute path section. Is it useful for us to have the concept of a JRoot or JDocument?
• MK: I didn’t feel it was useful to have different kinds of JNode in the type system.
  • … A JNode is either a root or a non-root, but I didn’t add it to the type system.
  • … I don’t see any operations that are different between those cases.
  • … But I suppose the same is true of subtypes of XML nodes.
  • … That could be added, but I didn’t see any value.
• JLO: If you select with an absolute path, you always get a JNode that is a root.
• MK: Slash itself will always select a parentless node.
• JLO: Oh, right, so what I said was wrong.
• WP: What would a schema language for JSON look like? Very cool.

Some discussion of the practical next steps.

• MK: What I propose doing is to come back with an editorially complete version except for the XSLT side. That will require technical work.
  • … Hopefully we can review it briefly next week and accept it.

The CG agrees to move on to some other open PRs.

See PR #2077

• CG: I’ve tried to unify things and bring it into alignment with other specifications.

CG summarizes the changes, generally.

• NW: I’m not sure that all operating systems define a last modified time for a directory.
  • … Maybe last-modified should return xs:dateTime?.
• CG: I’ll investigate.

CG continues a survey of the functions in the spec.

• NW: What about “/” and “\”?
• CG: I think that the user should use path-to-uri.
• JLO: I don’t know how often permissions are handled in this specification?
  • … Since we have a function to list all roots, that will likely raise permissions issues?
• CG: Permissions are fairly tricky.
  • … It’s very OS dependent.
• NW: It’s messy, even in Java.
• JLO: Do we raise issues if the OS raises them, or do we swallow them.
• CG: Unclear. I can think about error handling for those cases.
• JLO: From the very non-conformant eXist implementation, you can’t list roots unless you’re an administrator.
• CG: Some of the file module may be inaccessible if you don’t have administrator privileges.
• JK: This looks really good. Could we avoid “regular” because it makes me think of regular expressions.
  • … But perhaps we should define what it means.
• RD: Can we reference the POSIX spec?
• CG: Yes.

ACTION: QT4CG-128-01 CG to consider using “standard” or some other term instead of “regular” in the file: module. ACTION: QT4CG-128-02 CG to investigate what to say about permissions.

Proposal: accept this PR.

Accepted.

ACTION: QT4CG-128-03 NW to compare the file: module against the equivalent XProc 3.1 steps