QT4 CG Meeting 078 Minutes 2024-05-21

RD, EP gives regrets. JLY gives regrets for three weeks.

• [ ] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [ ] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [ ] John Lumley (JLY)
• [X] Dimitre Novatchev (DN)
• [X] Wendell Piez (WP) [:15-]
• [ ] Ed Porter (EP)
• [X] C. M. Sperberg-McQueen (MSM)
• [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 May 2024.

MK gives regrets. JLY gives regrets for two more weeks.

• [ ] QT4CG-063-06: MK to consider refactoring the declare item type syntax to something like declare record
• [ ] QT4CG-071-06: NW to clarify the cases that are distinguished by the leading empty string in path segments
• [ ] QT4CG-072-03: NW to clarify the round-tripping of URIs
• [X] QT4CG-073-01: NW to proceed with the records/options proposal and make a PR.
• [X] QT4CG-077-01: DN to create an issue for adding Blake-3.
• [X] QT4CG-077-02: JK to correct the reference to TR29.
• [ ] QT4CG-077-03: MK to add a note about document order across documents
• [ ] QT4CG-077-04: MK to review inconsistencies discovered in review of #1117

See PR #1117

• MK: We have the choice of specifying an encoding or an options map.
  • … Some confusion about how that worked in unparsed-text-lines
  • … I think that’s now sorted out.
• CG: The XQuery code for unparsed-text-lines is wrong
• MK: I think that’s now okay.

Proposal: accept this PR.

Accepted.

(We return to this following a question by CG)

• CG: In 3.1, different newline characters are allowed and automatically normalized
  • … Shall we change the default to “true” so that we’re backwards compatible?
• MSM: 👍
• MK: Thanks for spotting that.

ACTION: QT4CG-078-01: MK to make the default for normalize-newlines on unparsed-text.

See PR #1197.

• MK: We already have fn as an abbreviation in inline functions.
  • … This just allows it in normal function declarations.

Proposal: accept this PR.

Accepted.

See PR #1191.

• MK: This is doing the same kind of thing with the options parameter

(CG projects for MK)

• MK: Instead of a collation parameter and an options parameter, they’re combined

Proposal: accept this PR.

Accepted.

See PR #1185.

Skipped on first triage pass.

See PR #1227 See PR #1062 See PR #1027

Skipped on first triage pass.

See PR #1228

• MK: I have no objection, but that’s from a position of ignorance as to which ones are important enough. It’s a judgement call.
• WP: Not an expert on hashing algorithms, but in the context of what people are doing is how do things get added or removed from this list.
• NW: You can support any you want, this is about what’s in the standard.
• CG: I have no objection, but what if there are others that could be added? Why is this one more important?
• JLO: As long as there decent Blake3 implementations, then I think there’s no problem. I was hoping for HMAC, for example.
• DN: Why this one? With this one, we have five. CRC32 and MD5 should be uncontroversial. SHA1 and SHA256, which are known to have security exploits. Blake3 is the only one without exploits.
  • … Finally, I think five is the perfect number. And I think we should do it.
• CG projects rurban.github.io/smhasher/doc/table.html showing that there are many faster algorithms.
• DN: There are implementations already in Java, C#, and Rust.
• NW: That’s true of many, many algorithms. Adding a dependency isn’ty free.
• CG: I would like to discuss if further.

We’ll continue discussion of this item. Please comment on the issue or in email.

See PR #1219

• MK: It’s purely editorial, there are places where it still appears in examples and it’s incorrect.

Proposal: accept this PR.

Accepted.

See PR #1217

• MK: I resisted this initially, but CG was persuasive.
  • … My main reservation was what do you want back for [1] on an array?
  • … Now that you can have multiple numbers, it makes sense to return an array.
  • … The implementation required generalizing the predicate truth value and referring to it.
  • … You can also use it on maps which is probably useless, but logically consistent.

Proposal: accept this PR.

Accepted.

See PR #1213

• MK: Displays the way the signature of a variadic function is displays.

Proposal: accept this PR.

Accepted.

See PR #1212

• MK: This corrects the history and justification. It’s purely editorial.

Proposal: accept this PR.

Accepted.

See PR #1211

• MK: This just adds some examples.
• CG: I noticed some issues in union and choice types, but they’ve been corrected.

Proposal: accept this PR.

Accepted.

See PR #1209

• MK: I’ve tried to remove all the controversy from the discussion.
  • … This adds a new expression, transient {} which sets the static context to transient mode.
  • … This relaxes the implementation requirements for functions like current-dateTime, doc, etc. so that they are not required to be stable.
  • … No obligation on the implementation to do anything different, but it is allowed to relax the requirement to deliver the same results every time.
  • … There’s a recommendation about functions that might particularly benefit from this treatment.
  • … This is basically implementation-defined territory.
• DN: I’m wondering who would use this and why if implementations are not required to return different results every time? If users can’t know what will happen, why should they use it?
• MK: If you take the collection function, an implementation of the function that access the filestore, the requirement to make the collection stable is quite expensive.
  • … People are currently using proprietary extensions to say they want versions of the function that doesn’t incur the overhead.
  • … This provides a declarative way to address that common use case.
  • … Users might do this if they know their implementations will use it.
• DN: My concern is that if this not an obligation on implementations to change their behavior, they won’t change it.
• MK: That’s a valid concern given that the unordered expression is very rarely used. Most users want results ordered most of the time.
  • … You can’t force an implementation to return different results.
  • … We can’t formally model changes in the external environment.

Some discussion of what it means to observe the external. Some discussion of whether we should use the word “should”.

• NW: I think you underestimate how responsive implementors are to customers.
• JLO: I think fn:random-number-generator could be added to this list. That would make it more approachable by just returning a different value each time it’s called.
  • … I’m also wondering if it’s implementation-defined that a function like current-dateTime must return different values. It could be really problematic if an implementation returns the same value.
• MK: It’s just hard to predict the outside world, you can’t for example, determine whether or not caching will happen in the network.
• MSM: I wanted to say on the issue of encouraged-but-not-required-to versus should, “should” has a defined meaning in conformance. I think that would be a better choice here. And consistency helps readers.
• MK: Okay.
• WP: I think I agree with that. It’s a question of whether this should be in the specification or should be implementation behavior. It looks like a useful thing to have a standard way to say.

ACTION: QT4CG-078-02: MK to update the prose to use the word “should”.

• CG: My concerns are similar to DN’s. I have some doubt that implementors will do sufficiently consistent things. Maybe we could try to make it a little clearer what changes should be expected. For time measurements we already have another issue about that.
  • … One example is file append. That function is identified as non-deterministic so I wouldn’t expect transient{} to change anything.
• MK: There’s no determinism required by the specification for file append.

Some discussion of when an implementation might “know” that a function was nondeterministic. (Annotations or other API choices, perhaps.)

• CG: I’m not sure who would find this advantageous.
  • … What happens when a function is invoked through a function pointer, etc.
• MK: I’ve made it part of the static context. That would make it part of the context when the function is created, not invoked.

We’ll continue discussion of this item. Please comment on the PR or in email.