QT4 CG Meeting 020 Minutes 2023-01-31

Regrets: BTW, JK, EP.

• [ ] Anthony (Tony) Bufort (AB)
• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [ ] Joel Kalvesmaki (JK) [:12-]
• [X] Michael Kay (MK)
• [X] John Lumley (JL)
• [X] Dimitre Novatchev (DN)
• [ ] Ed Porter (EP)
• [ ] Liam Quin (LQ)
• [ ] Adam Retter
• [X] 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 agenda and minutes were not sent by email, chair apologizes.

The next meeting is scheduled for Tuesday, 7 February 2023.

No regrets heard.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
• [X] QT4CG-015-02: NW to improve the width of the diagrams, perhaps multiple views
• [X] QT4CG-015-04: NW to investigate of a dynamic presentation is practical
• [ ] QT4CG-016-02: NW to add an ed-note indicating when it was approved.
• [X] QT4CG-016-03: RD to add a note clarifying “known character encoding”
  • https://github.com/qt4cg/qtspecs/pull/330
• [X] QT4CG-016-04: RD to add a note clarifying the “*”/”*” html/version combination
  • https://github.com/qt4cg/qtspecs/pull/330
• [X] QT4CG-016-05: RD to add a “todo” noting the dependency on keyword arguments
  • https://github.com/qt4cg/qtspecs/pull/330
• [ ] QT4CG-016-06: RD to reword the introduction to mapping to clarify who’s doing the mapping
• [ ] QT4CG-016-07: NW to make an issue about the problems of document-uri uniqueness
• [ ] QT4CG-016-08: RD to clarify how namespace comparisons are performed.
• [ ] QT4CG-016-09: RD to add a note stating that the local name should always be lowercase
• [ ] QT4CG-016-10: RD to consider how to clarify parsed entity parsing.
• [ ] QT4CG-019-01: MK to fix the type of $pattern in fn:tokenize()
• [X] QT4CG-019-02: NW to revisit the width issue in the type diagrams

See pull request #319. We already have one approval for this PR.

MK provides a quick summary of the new fn:atomic-equal() function and its consequences.

• DN: If this is the same as op:same-key(); I see some duplication.
• MK: No, the old function op:same-key() no longer exists.

Proposal: accept this pull request

Accepted.

See pull request #320. Mike asks especially for careful review, this is not a simple change.

MK proposes to introduce and describe the changes.

• MK: Add an $options parameter; unfortunately the ~\(collation\) parameter can’t be merged into it.
  • … The $options defines how the comparisons are made
  • … The default values are all aligned with the 3.0 verison of the function

ACTION QT4CG-020-01: MK to check if the default for type-variety is correct.

• MK continues
  • … Options are designed so that if you set it to true, you get stricter comparisions. This explains the name of whitespace-retained.
• RD: Should the unordered comparison option apply to map keys as well?
  • MK: Map entries are always unordered…
• MK: Sequences are deep equal if their items are pair-wise deep-equal
• RD: Should we clarify the order in which fn:normalize-unicode and fn:normalize-space are applied.

ACTION QT4CG-020-02: MK to review the description of the equal-strings function

• MK: It’s much the same as before, except where the options come into play.
  • … The unordered-elements option is a bit subtle if you have mixed content or if there are multiple elements with the same name.
• JL: So you’re on your own if you have text nodes?
• MK: No, just don’t use it if you have text nodes.
• CG: Should it sort by node type so that it could work with mixed content?
• MK: Could do, but I thought it wasn’t going to be useful for mixed content.
  • … Of course, people do use mixed content in strange ways due to changes over time.
• MK: Type variety is a little more complex because it has to describe what’s meant by complex content and simple content.
  • … The logic for how we compare complex and simple content is preserved.

ACTION QT4CG-020-03: MK to add examples using options.

• RD: Would be nice to see examples based on intended usage, like around comparing two items in a unit test style.
• MK: I don’t want to go into enormous detail on use cases.
• DN: We have several functions where one of the parameters is a comparison function. In order to use deep-equal we need an option to return false instead of raising an error if an error occurs.
• MK: The only error condition is if there’s a function item; we simply don’t have a way of sensibly comparing function items.
• DN: Just return false.
• MK: But that would make a sequence not-equal to itself.
• DN: We can just spell out that it only equals itself if it contains no function items.
• MK: Where we talk about functions being deterministic, we claim processors can sometimes tell.
• DN: I’m not saying deep-equal should never return an error, just that it should be an option.

ACTION QT4CG-020-03: MK to add an option to return false instead of raising an error

• DN: If we don’t return errors for the same conditions, we’re losing some backwards compatibility

Some discussion of whether or not comparison of typed element content can raise an error.

• DN: I seem to recall that in the old version items were compared with the “eq” value so that times with and without timezones couldn’t be compared.
• MK: I’ll investigate that.
• RD: In the context of using this for things like implementing unit test assertions, one of the things I found useful for diagnostics was having the location where the failure occurred. Should we have an option to do that?
• MK: My plan was to add an fn:differences function that returns the differences, rather than just returning true or false.
• RD: Tangentially related fn:path only works for nodes. Should we extend it to maps and arrays?
• MK: Maybe,
• CG: Do we need the debug option if we have fn:differences?
• MK: Let’s wait and see.
• DN: In case where there are unordered elements and there are multiple groups with individuals that are the same, what is the order of the comparisons?
• MK: The current rule is very simple, simplistic even, it says you sort them by namespace and local name, and then you compare them. If you have multiple elements with the same name, their order is going to be significant.
• JL: What happens if the child elements themselves are in unordered sets?
• MK: The options are passed down.
• DN: I think this is a bit confusing?
• MK: Maybe I should change it to do a pure pair-wise set-comparison.
• DN: Yes.
• DN: Have you considered an implementation that just makes hashes and compares the hashes?
• MK: Yes, that’s the sort of thing. It’s note easy but it can be done.
• MSM: Question about the rule that says there’s a mapping, are you envisioning a 1:1 mapping or just that there is a mapping.
• MK: I was phrasing it as there must be a pairing: an ordering of A and B such that they are pairwise equal.
• MSM: So an empty element named E will not match in this comparison a sequence of 3 empty elements all named E.
• MK: No.

See pull request #326. We already have one approval for this PR.

• MK: In the current specs, support for higher order functions is optional. That’s not really viable anymore. All of the 3.1 implmentations we know about already support it.
• JL: Does that mean you have to implement all the HoF?
• MK: Yes.
• MSM: Is it really true? I thought eXist didn’t.
• MK: They don’t claim to be 3.1, do they?
• CG: I thought eXist did.
• MK: We’re defining so much functionality with HoF that you really have to implement them.

Some discussion of eXist’s support.

• MK: Making a feature mandatory doesn’t mean everyone will implement it!
• MSM: True, it just makes comparing conformance easier.
• MK: It also means it allows users to use features that they might not if it was optional.

Proposal: accept this PR

Accepted.

See pull request #324. We already have one approval for this PR.

MK reviews the XQuery version.

• MK: I moved string constructors and string concatenation into the same section.
  • … Proposed syntax is to use backtick delimited strings.
  • … The fixed part is just what it says, with escaped delimiters unescaped.
  • … The variable part works like attributes in XQuery (but not exactly like XSLT, unfortunately)
  • … That’s it, except for a few complications.
  • … One complication is that ampersands are treated slightly differently.
  • … There’s also a tokenization ambiguity: ``[1]. It’s resolved in favor of string constructor on the longest token rule.
• MK: If we didn’t have that rule, then XPath and XQuery would behave differently.
• DN: In other programming languages, this is called “string interpolation”, maybe we should use the same term.
• DN: I think there could be more than one variable part in a string interpolation, but the prose suggests that there can be only one.
• MK: It certainly can be more than one, as the syntax makes clear.
• DN: Okay, maybe there should be at least one example with more than one variable part.
• MK: That’s already true!
• CG: The name “template” is more familiar to me, it’s like JavaScript.
• MK: Yes, languages have different names for the same thing but slightly different syntaxes.
• RD: The XSLT spec already uses “attribute value templates” and “text value templates”.
• MK: We could call this “string value templates” if we really wanted to.
• RD: I think internal consistency is more important than consistency with other languages.
• MK: The thing I always ask myself is, if someone comes across this term in an error message and hasn’t read the spec, are they going to guess correctly what it’s referring to.
• SF: They’re called “template literals” in JavaScript. In others they’re called by different names.
• MK: I don’t want to cause it a literal because it’s an expression.
• DN: I wasn’t trying to force another name, I just thought it would be useful to mention “string interopolation” in the prose.
• SF: We should include “string interpolation” and “template literals”.

Proposal: accept this PR

Accepted.

See pull request #308.

NW introduces the changes.

• NW: Last week, several folks said these should just be lists. So I just made them lists!
• RD: Would it be possible to move the legend to the right?
• NW: I’ll see what I can do.

Proposal: accept this PR

Accepted.