QT4 CG Meeting 027 Minutes 2023-03-21

Regrets: BTW, MSM, DN

• [ ] Anthony (Tony) Bufort (AB)
• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] John Lumley (JL)
• [ ] Dimitre Novatchev (DN)
• [X] Ed Porter (EP)
• [ ] C. M. Sperberg-McQueen (MSM)
• [ ] 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 Tuesday, 28 March 2023.

ATTENTION: This meeting is scheduled at 16:00 local time in Europe and the UK. The United States switched to Daylight Saving Time starting on Sunday, 12 March 2023. Europe and the UK will switch to summer time on 26 March 2023. This meeting will return to its “usual” time, one hour earlier than last week in the United States.

No regrets heard.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
• [ ] QT4CG-016-08: RD to clarify how namespace comparisons are performed.
• [ ] QT4CG-023-01: NW to review the stylesheets for functions across XPath and XSLT
• [X] QT4CG-024-01: MK to add namespace-uri-for-prefix argument changes to the compatibility appendix
• [X] QT4CG-024-02: DN to develop an alternative proposal for deep-action.
• [X] QT4CG-025-02: MK to make the context function properties simple values instead of functions
• [ ] QT4CG-025-03: MK to revise and expand technical detail in PR #375
• [ ] QT4CG-025-04: RD to remove the note in 15.5.15 of functions and operators.
• [ ] QT4CG-026-01: MK to write a summary paper that outlines the decisions we need to make on “value sequences”

See PR pull request #391

• Some discussion of the naunces of the U+four-leading-digits convention.
• JK may try to improve the consistency; would CSS styles for Oxygen be useful?
• MK please make sure you don’t use an editor that changes whitespace!

Proposal: Accept this PR.

Accepted.

See PR pull request #393

• MK walks us through the PR; this is editorial in that it makes no changes to grammar or implementation but does make broad changes to the prose of the spec.
  • … Changed data model to use “function items” instead of “functions” because you need the distinction.
• RD: Is also consistent with map items and array items.
• MK: Changes the title of the section and explains why
  • … Changed “implementation” to “body”
• MK: Next let’s look at XQuery:
  • … Added a discussion of categories of functions (application, system, or external functions) and the distinctions between them.
  • … Context dependence is different in the three cases
• RD: This lays the groundwork for external framework bindings.
• MK: I’m not suggesting we do that, but yes, it’s a start.
  • … Rewrote the section on partial function application to give separate sets of rules for static and dynamic calls. Bundling it into a single set of rules had become too complex.
    • … And that’s about it.

Proposal: Accept this PR.

Accepted.

See PR pull request #394

• NW: This is almost too trivial for review. Basically, if you omit the “/”, the rest of the algorithm fails.

Proposal: Accept this PR.

Accepted.

See PR pull request #395

• NW: This one is a little more interesting. Basically, the functions fn:parse-uri and fn:build-uri should be reversible. If the parse function doesn’t record whether or not it treated the URI as a hierarchical URI or not, then it’s not always possible for the build function to do the right thing.
• MK: What about the question of file URIs and UNC names?
• NW: That’ll be in my next PR, I wanted to clear these so I didn’t have too big a merge tangle.
• RD: The WHAT WG has notes about file URIs too.
• NW: Thanks. I’ll look at that too.

Proposal: Accept this PR.

Accepted.

See PR pull request #396

• NW: I propose we wait until DN is present.

General agreement.

See PR pull request #400

• MK: This is mostly about XSLT, but I found some bugs in the pattern grammar
  • … Added type type() keyword to wrap a type. That was already in the proposal.
  • … What’s new is what we do about priorities.
    • … Import precedence first
    • … Priority next
      • … All type patterns have the same priority (0)
    • … Type patterns are distinguished according to the type hierarchy
      • … Discard supertypes (because you have a more specific one)
      • … With special rules for predicates (predicates win)
      • … If you’re left with a single rule, that’s it, otherwise do the same thing you would for any other case of duplicate matching templates.
• JL: I assume next-match will allow you to go to a less specific one?
• MK: Yes, I don’t think the rules don’t have to change.

ACTION QT4CG-027-01: MK to update the text for next-match wrt type() matching

Proposal: Accept this PR.

Accepted.

See issue #399

• NW: I propose we wait until DN is present.

General agreement again.

See issue #360

• MK: Balisage paper from last year
  • … This is about doing navigation across arrays and maps
  • … I started with an abstraction the “parcel”, but I’ve moved to a concrete representation
  • … Let’s review…
    • … Splits maps and arrays into two sections for editorial convenience
    • (Abandonning the diff version; too much text moved around)
    • … Looking at 19 Arrays
      • … New functions available to users, array:members and array:of
      • … A value record is a map with a single key “value”
      • … Looking at he specification for those functions, starting at array:members
      • … What’s interesting his how it’s used. Need more use cases.
• RD: Do we have a corresponding proposal for map:members and map:of?
• MK: Not yet, but my plan is to do that next.
  • … The problem with map is what we already have map:entries and that’s not precisely what I’d like. Would be better if it returned a map with two keys.
• RD: With this proposal you could potentially do array:of(map:members(…))
• MK: Yes.

Touching briefly on provenance, and agreeing to keep it separate.

• MK: The other primitives you need are how to get back. You can use “?” and just map('value':.)
  • … We could provide syntactic sugar, but this seems managable
• ML: What’s interesting is that these new functions get used in the description of many of the other functions, for example array:insert-before()
• CG: Could we possibly have an atomization of the array records?
  • … You can use them as input for arbitrary functions an you would get them to the right type.
• MK: I think the problem is if what I’ve called value records were a new data type, then we could certainly say atomization works on it. Or that it was implicitly coerced to an array. Because I’ve tried to make it a concrete reuse of maps, it’s harder to give it any special magic behavior. There’s a tradeoff.
• JL: There are no implications if I chose to use a map with a value key, that wouldn’t be special would it?
• MK: No.

Proposal: Accept this PR.

Accepted.

• RD: Local union types were added before the CG started. I was going to suggest we look at that.
• MK: Let’s look at 3.6.2.1 in XQuery
  • … The proposal is that the semantics are based on XSD union types. It has to be atomic types or union types.
  • … But the grammar just says ItemType, probably so you can put an enum in. We could restrict it to a type name so you have to name the enumerated type.
• RD: Or we could introduce a local element union type that’s an atomic type or an enum type.
• MK: Yes, that would possibly work.

MK reviews the semantics

• MK: The subsumption rules are defined, but they’re the same as XSD.
  • … It’s really just a way of saying that you can use a union type just like it was in a scheme, but you don’t have to write a schema to do it.