QT4 CG Meeting 127 Minutes 2025-07-01

Regrets: DB, JWL

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

JWL gives regrets for 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.
• [X] QT4CG-126-01: JLO to add an example where the map:build key function returns multiple keys.

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

• MK: How do we want to review this?
• JLO: I would like to discuss the concepts first.
• WP: I’d like examples too!
• MK: In that case, let’s start with the data model; that’s where the concepts are introduced.

MK reviews changes in the data model specification.

• MK: There’s some removing around; JNodes replaces a couple of concepts, so we lose labeled items.
  • … In the type system, we add a “generic node”. An unqualified use of the term “node()” means an XNode.
  • … A JNode can wrap any sequence, but the interesting cases are maps and arrays.
  • … The diagrams have changed but the diffs are confused.
• MK: Section 6, Generic nodes.
  • … GNode is a collective term for XNodes or JNodes.
  • … (etc.)
  • … Both XNodes and JNodes have unique identity and document order.

The data model document is now very asymmetric.

• MK: Any value can participate in a map or array and can be a value in a JTree.
  • … But the tree isn’t considered to extend to those nodes, it’s a context switch to a different space.
• JLO: So it’s a foreign object.
• MK: Yes. It’s like a ZIP file in a directory structure, it’s not part of the same tree.
• MK: A lot of things have been moved around.
• NW: I’m surprised there isn’t more to change about accessors.
• MK: Section 8.4 introduces JNodes in more detail.
  • … I’ve kept the ¶ notation so that they stand out.
  • … The term “value” in particular is usefully distinguised ¶value.
  • … A JNode always wraps a value and if it isn’t the root it has a parent and a selector which is it’s key or index. And it has a position.
  • We have to cater to the possibility that an array item will contain more than one map.
• MK: There’s an accessor j-children that returns the children.
• MK: Values can be leaf or non-leaf values; it’s a non-leaf if at least one item in the value is a non-empty map or array.
  • … There’s a lot of subtlety in that sentence!
  • … You can distinguish them, but it’s a bit complicted.
• RD: Would it make more sense to define JNodes using data model parent and other properties that are done for the XML node types. Then things like the child selector and parent and such are all in effect defined by those data model functions.
• MK: There are some similarities but many differences. I’ve tried to move what is common up to the GNode level and keep what I couldn’t integrate at the next level.
  • … It gets terribly complicated if you try to go too far.

Some discussion of how things like the attributes accessor might work.

• MK: If the ¶value is non-leaf, then it contains one or more JNodes for each member.
  • … There’s an accessor dm:j-value that is used to access the value.
  • … The function dm:JNode can be used to wrap a value.

MK explains the code that follows the introduction of dm:j-value and dm:JNode.

• MK: You don’t get a JNode for entries in an array that don’t contain more nodes. That’s different from how text nodes work. Here you just get atomics at the root level.

MK describes the examples.

• NW: I wonder if we could improve on “position” and “selector”.
• JLO: What is the necessity to allow for sequences in JNodes? Is it a must-have?
• MK: Yes, it has to be possible to process all maps and arrays, rather than just ones that represent well-formed JSON.
• JLO: If I have a sequence of 14 empty arrays, then it will be a leaf node?
• MK: Yep. Basically, if you haven’t got any children, then you have to do some conventional processing on the value to work out what you’ve got.
• JLO: The really hard part is to distinguish empty arrays and maps.
• MK: Yes, the JSON value null turns into an empty sequence and that has no children either.

Some discussion of distinguishing empty arrays and null.

MK discusses the example of a JTree representing arbitrary XDM content.

ACTION: QT4CG-127-01: NW to diagram the JTree representing arbitrary XDM content.

• WP: (Scrolling back up a little) Are there cases where you’re going to have the same selector in different positions?
• MK: Yes. If the third element has two items.
• MK: There’s some effort here to make the 90% case easier; but it does squash a few things that make the 10% case more complicated.
• MK: Every root JNode has its own identity.
  • … For a non-root JNode, the identity is a function of its properties. (If they have the same ¶parent, ¶position, and ¶selector, they are the same JNode.)

JNodes are likely to be lazily constructed. Parent pointers are transient. This is like the “Zipper” data structure frequently found in functional programming.

• JK: I have some knotty questions about terms, but we can come back to those.

MK turns to the XPath specification.

• MK: There are two new item types, GNodeType and JNodeType.
• MK: There’s new exposition about what the types mean and what they match, but they’re obvious.
  • … So are the subtyping rules.
• MK: Coercion rules say that if you supply a JNode where one isn’t accepted, then you substitute its value. (A map or array function will accept a JNode and implicitly unwrap it.)
• MK: Union, intersect, and except are generalized to apply to both JNodes and XNodes.
• MK: Similarly, the “is”, “before” and “after” operators apply to JNodes.
• MK: Then we get to Lookup Expressions.

MK reviews the details of lookup expressions.

• MK: If there is no axis, it almost but not quite defaults to child.
  • … The distinction is that it unwraps the nodes to give you the values. That’s consistent with what we currently have.

MK moves on to deep lookup.

• MK: This is new in 4.0, so we can change the semantics and I have, it is just the ancestor access.

MK skims over the changes to Functions & Operators.

• MK: fn:root, fn:generate-id and fn:distinct-ordered-nodes have been generalized to GNodes
  • … We could do others.

NW wonders how to proceed…

• CG: I think this is a big step forward. There’s one thing that keeps me thinking, it’s the question of whether we should overload the existing lookup operator that was in 3.0. I wonder if we should keep lookup expression as it is and introduce a new expression, like JPath, that is much more similar to an existing XPath expression.
  • … That would give us more freedom to define the semantics. Mostly we could make the simple step symmetric with the child axis.
  • … One problem is that ?b and ?child::b will produce different results and that will be problematic.
• MK: Yes, there are a few surprises in here.
  • … You suggested using a different operator. I looked at “/” but decided that wasn’t viable.
• MK: How does that effect the discussion of adopting this as baseline.
  • … My preference would be to adopt this and work from here. That will make proprosed improvements easier.
• CG: I think it could be a pretty fundamental change if we decided to leave the lookup operator untouched.
• MK: Hopefully that would only effect lookup expressions.
• JK: I’d like to have more time to review it. I have some fundamental questions about how we’re addressing the data model.
• RD: I wondering about the JPath syntax which I quite like. I wonder whether it would make sense to instead of having a separate syntax, keep the existing syntax and somehow do something mixed.
• CG: The main challenge is that we cannot redefine the shallow lookup operator.
• RD: I’m thinking of “//”, given that we’re defining the parent and other things.
  • … I think with care the existing XPath syntax should fall out and be compatible.
• JLO: I’d like more time.