QT4 CG Meeting 071 Minutes 2024-03-26

• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Mukul Gandhi (MG)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JLY)
• [X] Dimitre Novatchev (DN)
• [X] Wendell Piez (WP)
• [ ] Ed Porter (EP)
• [ ] Liam Quin (LQ)
• [ ] Adam Retter (AR)
• [X] C. M. Sperberg-McQueen (MSM)
• [X] Norm Tovey-Walsh (NW). Scribe. Chair.

Proposal: Accept the agenda.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is scheduled for Tuesday, 9 April 2024.

The CG will not meet on 2 April 2024.

WP, JK gives regret for 9 April.

• [X] QT4CG-063-04: NW to try to add test review to the editorial meeting.
• [ ] QT4CG-063-06: MK to consider refactoring the declare item type syntax to something like declare record
• [ ] QT4CG-064-08: NW to open an issue to try to resolve $search to $target consistently.
• [-] QT4CG-069-02: NW to coordinate with MK to use the introspection features on the test suite.
  • In progress…
• [ ] QT4CG-070-01: NW to review how records are formatted.
• [X] QT4CG-070-02: MK to raise the line separators issue in parse-csv.

See PR #1071: 1070 Bare Brace map constructor syntax

MK summarizes the proposed change. p

• MK: The map keyword left the plain braces available for other features, but those features no longer exist.
• JLO: The main question I have is, will this be problematic in places where we do have curly braces in XML.
• MK: The only place where you would be likely to have problems are where you have a map or a string where you could have element content.
• RD: Curly braces in an XML literal switches the contexts. So if you have { } and your map in that, that’s fine. But because of XQuery uses }} in the XML context as an escaped }, you’d have to avoid that.
• DN: I’m really not sure there isn’t ambiguity here. What about the body of a function? How do we distinguish it from a map. And didn’t we do something with if/then/else to use braces.
• MK: There are no expressions that begin with curly braces, so it doesn’t appear to be a problem.
• RD: Those are all defined in terms of contained expressions.
• MK: There’s ambiguity in the sense that the grammar is ambiguous and I don’t think we have any technical ambiguities in that sense. There’s also ambiguity that confuses the reader, you might want to continue to use the map keyword for that.
• JLY: I had the same comment as DN; use the map keyword.
• WP: (inaudible)

Something about attribute value templates.

• MK: That’s like the other cases; but those are always strings so it’s even less likely.

Proposal: Merge this PR.

Accepted.

ACTION: QT4CG-071-02: MK to raise a PR that changes map construction examples as appropriate

See PR #1059

• NW: We’ve talked about this a couple of times. CG’s revision makes it an error to use unknown options only if they are in no namespace.
• CG: That’s right.

Proposal: accept this PR

Accepted.

See PR #1100: 99 fn:equal() function to compare sequences and arrays

MK introduces the PR.

• MK: This is a function that can compare anything and is parameterized at the item level about how it does the comparison.
  • … Fills out the family of starts-with/ends-with etc. functions
• CG: I think we need to check if the second map contains a value because the value can be an empty sequence.

Some discussion of the finer details here. A missing key vs. a key with the value of an empty sequence. {a:()} vs {b:()}, for example.

ACTION: QT4CG-071-03: MK to review the definition of map equality in fn:equal

• MK: It’s different from fn:deep-equal primarily in that the comparison is parameterized.
• JLY: Given that the fn:deep-equal and fn:equal are both descending comparisons, both sections should highlight the differences.

ACTION: QT4CG-071-04: MK to update the prose to highlight differences between fn:equal and fn:deep-equal

• DN: We need to know more about the differences between this and fn:deep-equal. It can be confusing. In all these signatures, the comparison function is confusing. Rather than equality comparison, I’d like a more general comparison, not just equality.
  • … For example, consider a sort key where you might produce an array and you should be able to compare arrays as sort keys.
• MK: Those are all good points. I have the same dilemma, we have too many comparison functions and not enough! I’d like to find a different name. I do think we need a straight equality comparison to complement the subsequence-equals/starts-with/etc. functions. You can’t just use a general comparison because not all atomic values are ordered.
• DN: The name of the argument could be equality-comparer.
• MK: It’s a bit long for a keyword; there’s always a tension in naming.

ACTION: QT4CG-071-05: MK to consider the name of the function argument.

• CG: Another challenge is the existence of the comparitor function. A user might expect to use it here. I think it would be reasonable to add it for this case as well. Then there’s a question of nodes vs. atomic values. Many comparisons atomize and that might create different results.
• MK: Then it quickly becomes non-transitive.

Some discussion of the examples.

• JLO: Maybe it’s really useful to point out what a leaf is.

Some discussion of whether or not that term is in the spec.

• DN: It seems strange that there are no collations here.
• MK: I felt you could supply a comparison callback that uses a collation.

(From the chat, there is some discussion of whether or not a comparison function should be made available to fn:deep-equal)

MK will make another pass.

See PR #1077

MK introduces the PR; it just changes the change log.

• MK: It resolves the fact that we have now discussed all the features.
• CG: I think so.

Proposal: merge this PR.

Accepted.

See PR #1074

• MK: this is the same thing for Functions and Operators.
  • … It removes the fn:json function as that’s the subject of a PR in flight.
• CG: I have some concerns regarding fn:stack-trace; that’s actually still an open issues.
  • … The same is true of map:replace and array:replace.

Proposal: merge this PR.

Accepted.

See PR #1098: 566-partial Editorial improvements per recent discussion

• CG: I think there’s a comment in the PR that wasn’t addressed.
• NW: Oh…

Some discussion of why the leading empty string is necessary in path segments.

ACTION: QT4CG-071-06: NW to clarify the cases that are distinguished by the leading empty string in path segments

And we’ve run out of time.