QT4 CG Meeting 107 Minutes 2025-01-28

Regrets: SF.

• [X] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [ ] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:05-]
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] 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.

This next meeting is planned for 4 February 2025.

MK, JWL (possible) gives regrets. CG gives regrets for 11 and 18 February.

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

• [ ] QT4CG-082-02: DN to work with MK to come to agreement on the fn:ranks proposal
• [ ] QT4CG-088-04: [Someone] needs to update the processing model diagram needs vis-a-vis the static typing feature
• [ ] QT4CG-097-02: MK to make the XSD schema component references into links to XSD
• [ ] QT4CG-103-01: MK to add an example of showing all the properties for an untyped node.
• [ ] QT4CG-106-01: NW to remove the dead wood from the XSLT build (SVG diagrams)
• [X] QT4CG-106-02: MK to apply the typos changes and then merge this PR #1703.
• [X] QT4CG-106-03: MK to write the XPath that puts map keys in record order as an example.

See PR #1708

MK introduces the PR which does include a few small changes to XPath.

• MK: First try was, can we do this instead of named item types. I was persuaded to provide both.

MK walks through the XSLT spec changes.

• MK: The named item type section is largely rewritten but not changed in substance.
  • … Named record types is the new feature.
  • … There’s a detailed explanation of how a record type is equivalent to an item type and a function.

Some discussion of packages and visibility.

• JWL: When you have a record type with optional fields, does that imply that the constructor function is variadic?
• MK: Yes. The defaults become defaults in the function.
• JWL: They’re not overridable outside a package, so there’s nothing like xsl:original-reference.
• MK: Right. Overriding a type would have such unpredicatable consequences, we probably don’t want to consider it.
• JWL: If I do a function override, from a package where I can refer to the original, do I still keep the same type?
• MK: The overriding function has to have a “compatible” type signature.

Proposal: Accept this PR.

Accept this PR.

See PR #1722

• MK: This is very straightforward. It just changes how we define focus functions.
  • … It just adds a paragraph establishing the relationship between focus functions and the focus setting operator.
• CG: Was wondering if we should add the return type.
• MK: Yes.

ACTION QT4CG-107-01: MK to amend PR 1722 so the expansion of focus functions includes the return type item()*

Proposal: Accept this PR.

Accept this PR. MK to merge after completing the action.

See PR #1727

• MK: When implementing this and writing tests, I discovered we hadn’t been clear enough about duplicates in a few places.
  • … In fn:map-build, we clarify how duplicates are handled.
  • … In fn:map-merge, we do the same thing.
    • … But there is some sublty here.
  • … In fn:map-of-pairs, we also do the same thing.
• CG: I like to have the option combine for map-merge as well. What about duplicates on map-build?
• MK: I have no objection. It gives you two ways to do the same thing that makes me a little uneasy. Should we add the options to all the functions?

ACTION QT4CG-107-02: MK to propose adding the "duplicates" option (from map:merge) to map:build and map:of-pairs

• NW: If we don’t, users will wonder why?
• MK: Yes, okay.
• JLO: Why is it implementation defined which key is used when there are duplicates?
• MK: That’s a valid point. You could always just the first one.

ACTION QT4CG-107-03: MK to propose amending all the functions that return ordered maps so that when duplicates are found, the key of the combined entry is taken from the first of the duplicates.

• CG: There’s a use of random in map:merge and there’s a typo.

ACTION QT4CG-107-04: MK to review CG’s comment to align fn:map-merge by removing the reference to random number generator and fixing a typo.

Proposal: Accept this PR.

Accept this PR.

At some point in the life of a working group, the consensus shifts from “there’s more to do” to “we need to finish”. I think the QT4CG is starting to feel that tension.

Discuss.

• MK: What are we doing about external review?
• NW: I thnk we shold
• MK: What about pointing
• NW: Yes, a fixed URI
• MK: We need to revisit the question of what we need to finish to make the publication coherent, as distinct from what we’d like to do. We should focus on resolving the half baked ideas.

Some discussion. Revisit open issues? How to categorize?

• NW: I’ll make time on the agenda to categorize (or review, as appropriate) issues.
• JWL: My interest in XSLT is that we could go through the big things, which are finished, which need a little work, which should be dropped.
  • … I think we could go through it on big group bits.
  • … Maybe be in a clearer position by Easter?
• NW: Let’s consider doing this during the two weeks that CG will be away (with his approval).
• DN: I really want to publish a PR about generators, kollections, and … but I’m blocked because I don’t know if we have the capability to have system defined records. That’s not been solved at all.
• NW: What do you mean by system defined records?
• MK: Try smaller pieces, do the system defined records first.
• DN: When I first confronted by this difficulty, I raised an issue. But that has been closed without action.

Some discussion of how complicated it is to make the PR.

• JLO: Somewhat related to what DN said. Record types that are known to the system is something I’m keen about with respect to options. I’d like users to be able to find out what is possible. And it would be good to be able to specify a type for them.
  • … We should have a list of them and what they’re types are. Maybe I could work with DN on that part.

ACTION QT4CG-107-05: JLO and DN to consider a proposal for system defined records.