QT4CG meeting 127 draft minutes, 1 July 2025

Hi folks,

Here are the minutes from today’s meeting:

   https://qt4cg.org/meeting/minutes/2025/07-01.html

Let’s try to keep the discussion going throughout the week so that we can have a productive meeting next week.

QT4 CG Meeting 127 Minutes 2025-07-01

   [1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
   Pull Requests

Table of Contents

     * [6]Draft Minutes
     * [7]Summary of new and continuing actions [0/7]
     * [8]1. Administrivia
          + [9]1.1. Roll call [8/12]
          + [10]1.2. Accept the agenda
          + [11]1.3. Approve minutes of the previous meeting
          + [12]1.4. Next meeting
          + [13]1.5. Review of open action items [1/6]
          + [14]1.6. Review of open pull requests and issues
               o [15]1.6.1. Blocked
               o [16]1.6.2. Merge without discussion
               o [17]1.6.3. Close without action
               o [18]1.6.4. Substantive PRs
     * [19]2. Technical agenda
          + [20]2.1. PR #2031: 2025 JNodes
     * [21]3. Any other business
     * [22]4. Adjourned

Draft Minutes

Summary of new and continuing actions [0/7]

     * [ ] 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.

1. Administrivia

1.1. Roll call [8/12]

   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.

1.2. Accept the agenda

   Proposal: Accept [23]the agenda.

   Accepted.

1.3. Approve minutes of the previous meeting

   Proposal: Accept [24]the minutes of the previous meeting.

   Accepted.

1.4. Next meeting

   The next meeting is scheduled for 8 July 2025.

   JWL gives regrets for 8 July.

1.5. Review of open action items [1/6]

   (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.

1.6. Review of open pull requests and issues

   This section summarizes all of the issues and pull requests that need
   to be resolved before we can finish. See [25]Technical Agenda below for
   the focus of this meeting.

1.6.1. Blocked

   The following PRs are open but have merge conflicts or comments which
   suggest they aren't ready for action.
     * PR [26]#2063: 1996 Lookups, KeySpecifier: Literal, ContextValueRef
     * PR [27]#2019: 1776: XSLT template rules for maps and array
     * PR [28]#1283: 77b Update expressions
     * PR [29]#1062: 150bis revised proposal for fn:ranks

1.6.2. Merge without discussion

   The following PRs are editorial, small, or otherwise appeared to be
   uncontroversial when the agenda was prepared. The chairs propose that
   these can be merged without discussion. If you think discussion is
   necessary, please say so.
     * PR [30]#2050: 2040 Fix context value declaration issues

   Proposal: accept without discussion.

   Accepted.

1.6.3. Close without action

   It has been proposed that the following issues be closed without
   action. If you think discussion is necessary, please say so.
     * Issue [31]#1903: fn:scan-left, fn:scan-right: missing steps
     * Issue [32]#1583: JSON: Parsing and serializing numbers, often
       undesired E notation
     * Issue [33]#1021: Extend fn:doc, fn:collection and fn:uri-collection
       with options maps
     * Issue [34]#967: XPath Appendix I: Comparisons

   Proposal: close with no further action.

   Accepted.

1.6.4. Substantive PRs

   The following substantive PRs were open when this agenda was prepared.
     * PR [35]#2031: 2025 JNodes
     * PR [36]#2043: 2038 Tweak the rules for fn:apply-templates
       references to modes
     * PR [37]#2037: 2036 Add rule for streamability of xsl:map
     * PR [38]#2019: 1776: XSLT template rules for maps and array
     * PR [39]#2014: QT4CG-122-01 Add notes, examples, and rationale for
       xsl:select
     * PR [40]#2011: 675(part): Add XSLT static typing rules for new kinds
       of XPath expression

2. Technical agenda

   This week, our plan is to focus on the JNodes proposal. Failing that,
   we'll see if we can resolve any of the other open PRs.

2.1. PR #2031: 2025 JNodes

   See PR [41]#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.

3. Any other business

   None heard.

4. Adjourned

References

   1. https://qt4cg.org/meeting/minutes/
   2. https://qt4cg.org/
   3. https://qt4cg.org/dashboard
   4. https://github.com/qt4cg/qtspecs/issues
   5. https://github.com/qt4cg/qtspecs/pulls
   6. https://qt4cg.org/meeting/minutes/2025/07-01.html#minutes
   7. https://qt4cg.org/meeting/minutes/2025/07-01.html#new-actions
   8. https://qt4cg.org/meeting/minutes/2025/07-01.html#administrivia
   9. https://qt4cg.org/meeting/minutes/2025/07-01.html#roll-call
  10. https://qt4cg.org/meeting/minutes/2025/07-01.html#agenda
  11. https://qt4cg.org/meeting/minutes/2025/07-01.html#approve-minutes
  12. https://qt4cg.org/meeting/minutes/2025/07-01.html#next-meeting
  13. https://qt4cg.org/meeting/minutes/2025/07-01.html#open-actions
  14. https://qt4cg.org/meeting/minutes/2025/07-01.html#open-pull-requests
  15. https://qt4cg.org/meeting/minutes/2025/07-01.html#blocked
  16. https://qt4cg.org/meeting/minutes/2025/07-01.html#merge-without-discussion
  17. https://qt4cg.org/meeting/minutes/2025/07-01.html#close-without-action
  18. https://qt4cg.org/meeting/minutes/2025/07-01.html#substantive
  19. https://qt4cg.org/meeting/minutes/2025/07-01.html#technical-agenda
  20. https://qt4cg.org/meeting/minutes/2025/07-01.html#h-9B6561A3-42E4-446B-BD54-64E818A607D6
  21. https://qt4cg.org/meeting/minutes/2025/07-01.html#any-other-business
  22. https://qt4cg.org/meeting/minutes/2025/07-01.html#adjourned
  23. https://qt4cg.org/meeting/agenda/2025/07-01.html
  24. https://qt4cg.org/meeting/minutes/2025/06-24.html
  25. https://qt4cg.org/meeting/minutes/2025/07-01.html#technical-agenda
  26. https://qt4cg.org/dashboard/#pr-2063
  27. https://qt4cg.org/dashboard/#pr-2019
  28. https://qt4cg.org/dashboard/#pr-1283
  29. https://qt4cg.org/dashboard/#pr-1062
  30. https://qt4cg.org/dashboard/#pr-2050
  31. https://github.com/qt4cg/qtspecs/issues/1903
  32. https://github.com/qt4cg/qtspecs/issues/1583
  33. https://github.com/qt4cg/qtspecs/issues/1021
  34. https://github.com/qt4cg/qtspecs/issues/967
  35. https://qt4cg.org/dashboard/#pr-2031
  36. https://qt4cg.org/dashboard/#pr-2043
  37. https://qt4cg.org/dashboard/#pr-2037
  38. https://qt4cg.org/dashboard/#pr-2019
  39. https://qt4cg.org/dashboard/#pr-2014
  40. https://qt4cg.org/dashboard/#pr-2011
  41. https://qt4cg.org/dashboard/#pr-2031


                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 1 July 2025 16:21:47 UTC