QT4 CG Meeting 079 Minutes 2024-05-28

MK gives regrets. JLY gives regrets for this week and next.

• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [ ] Michael Kay (MK)
• [ ] Juri Leino (JLO)
• [ ] John Lumley (JLY)
• [X] Dimitre Novatchev (DN)
• [X] Wendell Piez (WP)
• [X] 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 the face-to-face the face-to-face meeting on 4 and 5 June in Prague.

• [ ] QT4CG-063-06: MK to consider refactoring the declare item type syntax to something like declare record
• [X] QT4CG-071-06: NW to clarify the cases that are distinguished by the leading empty string in path segments
• [X] QT4CG-072-03: NW to clarify the round-tripping of URIs
• [ ] 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
• [ ] QT4CG-078-01: MK to make the default for normalize-newlines backwards compatible.
• [ ] QT4CG-078-02: MK to update the prose of transient{} to use the word “should”.

See PR #1237

Proposal: accept this PR.

Accepted.

See PR #1228

Straw poll: add BLAKE3? In favor: 4, opposed: 1.

• CG: The question is whether to do exactly this algorithm and not others?
• DN: My proposal should be regarded in a more general sense. There are faster algorithms, but many quality and security issues. This is just my opinion for a modern, better algorithm. Even if we merge this, let’s consider if we want to have at least one modern algorithm. It doesn’t have to be this one.
• RD: I wonder if it would be worth having a review of hasing algorithms implemented in different languages. XQuery and XSLT processors are implemented in many languages. Rather than making a specific decision on this now, say “these are the common algorithms that are readily available.” That lets us choose a suitable set or required and/or recommended algorithms.
• MSM: What I’m hearing is that we should think generally and not just about hashing algorithms but also the criteria by which we choose. I don’t have any suggestions. A systematic decision would be better than a casual one. I think that means someone needs to volunteer to do research.
• RD: I wonder if it might make sense to add additional functions: one that’s a default hash that returns the name of a sensible default hashing algorithm recommended by the implementor. And maybe an available-algorithms function.
• DN: I heard what RD said, but I think we’re deviating far away from the original proposal. I think we just need one modern algorithm.
  • … What MSM said is true, it would really be great if someone could do some research.
• WP: I agree with everything I’ve heard so far. Managing the list is a hard problem. I feel a little on the hook because I work with the sorts of people who could answer the question.

ACTION: QT4CG-079-01: WP to seek expert advice on hashing functions.

• CG: One question regarding the current proposal: this is BLAKE3 without the defaults. What about supporting keyed hashes?
• DN: If we get expert advice, hopefully that question will be answered.
• NW: I implemented all of the BLAKE3 options to amuse myself one evening; I

j think it wouldn’t be easy with the current function signature.

• JK: I like the idea RD has of a hashes-available function.
• RD: I just checked and Java has an API that supports testing what algorithms are available.

Proposal: leave this until we hear back from WP.

• See PR #1227
• See PR #1062
• See PR #1027
• DN: I’m a little reluctant to talk in the absence of MK. I just wanted to say that I don’t think the proposals are in that much conflict. With two proposals, we should try to synthesize what’s best between them.
  • … My proposal is a radical simplification, just a single key function. There was a long discussion and I proved it was possible.
  • … I am not insisting on a key function, so we can use the approach that MK took.
  • … What I think is missing in MK’s proposal is an additional argument that by default only creates distinct items in every rank.
  • … This is a new function, so we could reorder the arguments so that the collation sequence is not so awkward to use.
• NW: Can you attempt to work with MK to come up with a unified proposal.

Leave until after XML Prague. DN will attempt to work with MK.

See PR #1108

NW attempts to describe the PR.

• RD: Do we want to specify that the path segment characters are encoded exclusively or do we want implementors to be allowed to encode additional ones.
• NW: I think it would be better if we had a single algorithm for all implementations.
• CG: Did you have time to look at the test cases?
• NW: I did, but I don’t have a PR yet.

Proposal: merge this PR.

Accepted.

NW describes his recent rewrite of fn:parse-uri for discussion in the future.

See PR #1185

CG: Introduced merge conflicts; looking at the issue instead.

• CG: We could drop the array-values and map-values functions and just use array:get and map:get.
  • … We could extend the functions to get more functionality by making the arguments optional.

Some discussion of how wildcard arguments and the function syntax intract.

• MSM: I guess it’s not quite orthogonality, but more user expectations, should we consider: would it be better to allow the functional form to accept an argument of * just for parallelism?
• CG: I think if the * is a string, it’ll already give that value.
• RD: I was going to suggest updating the XPath spec, but I see it’s been updated to use the pairs accessor and things so we don’t need to update it to say map?* is equivalent to map:get() although it may be worth adding that in a note in XPath.

Some discussion of the goal: it’s to get a flat sequence.

• DN: Do we have a good way to represent the unflattened members or values? We’re losing information and not considering the question of getting the data without loss. I think that the operator MK introduced is sufficient.
• CG: I’m not sure how that’s related to this issue. How would you use the new syntax here?

Some question if there was confusion about the question.

• RD: With the new lookup modifier, the items modifier returns the flat list. Pairs returns the pairs and values returns a structured sequence of arrays to preserve the grouping. You can use those.
  • … If you want specific values, you can specify those in a parenthesized sequence to the lookup operator.
• CG: Yes.
• DN: Maybe we need more examples?
• RD: There are examples in the postfix lookup section.
• DN: But I mean for these functions. We need to do a better job of grouping things together. We should have a single section on records, for example.
• CG: I think the best way is to create a separate issue on that.
  • … My hope was to make it easier with these two functions.
• NW: I think reducing the number of functions is good.

CG agrees to finalize the PR after the meeting.

See issue #850

• RD: MK has opened a PR that needs sorting. I was planning on removing most of the supported HTML variants and just saying use HTML 5.
  • … We can just say HTML 5 or later.
  • … I’ll work on simplifying the API arguments.

RD to perhaps work with MK on the open PR.