QT4 CG Meeting 074 Minutes 2024-04-23

Regrets: JLY.

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

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

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

JLO gives regrets.

• [ ] 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-072-04: DN to raise an issue about having a function to test if a collation URI is supported
• [ ] QT4CG-073-01: NW to proceed with the records/options proposal and make a PR.

See PR #1163

MK reviews the proposal.

• MK: This is driven by the fact that we generalized context node to context item.
  • … The filter must be a boolean, it doesn’t use the EBV.
  • … This means it isn’t confused with positional selection.
  • … You can use position() and last()
• RD: I’d prefer it if the ?[ wasn’t a single token. It could be confusing for users and you might want to put whitespace to format the expression, for example putting then [ on a newline.
• DN: I like this, but I take the opposition position from RD. I think allowing whitespace or comments between the characters would increase the possibility of error.
  • … I’m a little bit concerned that we have too many “ideograms” in the syntax. The possibility of accidental errors are increasing.
• SF: I think the use of key and value limits the options for accessing earlier keys in the scope. It would be nice to allow additional syntax to allow you to explicitly say the key and value have a particular name.
• MK: You can do that with the more verbose syntax using map or array functions. Part of the general culture of the XPath language includes the notion of overriding scopes (consider .).
• SF: I’m talking about making extending it later on.
• CG: I like the proposal; I’d certainly use it. I know that some folks will think it’s too much syntactic sugar.
• RD: On the DN’s point, we already have “?*” that can be separated by whitespace, so I don’t see how that’s different form “?[“. I wonder if makes sense to move this into a lookup section. That would mean you could use this on the “??” operator.
• MK: That’s one reason why I didn’t do it there. The semantics become quite complicated doing it there!
  • … One reason I didn’t integrate it into lookup expressions is that it does’t do flattening the way lookup expressions do.
• CG: Another remark that I’ve already made in the comments is that in many places we’re trying to align arrays and maps, but we’re doing something different here.
• MK: We tried to make arrays and maps as consistent as we can, given that they’re different.
• RD: Wouldn’t this allow with the for/member discussions? That’s a kind of symmetry.
• MK: One way you could do it is to try treat an array as being a map with integer keys. But when you look at what people would have to write it’s far less convenient.
• RD: Or if you flattened the map into singleton maps, that makes access difficult.

Some discussion of how the feature differs from sequences; it’s about the fact that arrays can have items that don’t have single items in them.

Straw poll: “?[“ as a single token or two tokens?

Single token: 4 Two tokens: 2

I think single tokens wins.

Proposal: accept the PR.

Accepted.

See PR #1157

• MK: This is relatively minor.
  • … This fixes the bug with narrative prose.

Proposal: accept the PR.

Accepted.

See PR #1148

Not ready for review. Something has gone wrong in the editing.

See PR #1137

• MK: This proposal takes a mininalist approach. It generalizes what the concat function does and applies them to other functions. A lot of the discussion in the issue was about more comprehensive options. This just fixes the fact that concat stands out like a sore thumb.
  • … Having said all that, there’s an issue with concat in backwards compatibility mode that I couldn’t sort out in a fully general way!
• MK: It changes concat to be one of these variadic functions, but most of the technical changes are in the expressions.
• MK: I’ve reorganized the static context section a bit.
  • … Function declarations can now be declared to be variadic

MK reviews the description in 4.3 Variadic functions

• DN: Not directly related, but I understand that function items can’t be variadic. But in our current specification, do we allow arguments of function items to have default values?
• MK: No. I think that’s fairly orthogonal. We could potentially do that.
• MSM: I’m confused by MK’s answer to that question. I seem to remember a proposal that provided for that.
• MK: That’s only on static function calls, not dynamic ones.
• RD: Did you talk about default values? I see that concat uses it.

Some discussion of what happens when you call a variadic function that has a default that isn’t the empty sequence.

• MK: If the default wasn’t an empty sequence, there’d be some confusion there. If the occurrence is *, we could insist that it be the empty sequence.
• DN: I was going to say that it seems logical not to allow defaults for variadic arguments. That would eliminate the problem.
• RD: 👍

ACTION: QT4CG-074-01: MK to remove default values from variadic arguments

ACTION: QT4CG-074-02: DN to create an issue about allowing function arguments to have default values

ACTION: QT4CG-074-03: MK to add variadic functions to the XSLT specification

See PR #1125

• MK: This PR is attempting to address the problem of flattening.
  • … It extends the syntax of lookup expressions to add a modifier before the key specifier. It specifies pairs, keys, values, or items. Items gives the current behavior and that’s the default.
  • … This PR also adds the type qualifier. It solves the previous issue related to ambiguity around “?” by putting the sequence type in parenthesis.
  • … The type qualifier returns only items that match the specified type.

MK reviews examples from the specification.

• MK: This is very symmetric between arrays and maps.
• RD: With the type specifier syntax, do we want to align the keyword with the item type declaration?
• MK: It’s a sequence type not an item type.

Some discussion of item type versus sequence type.

• DN: It seems that using pairs or keys for arrays is not very useful. Also, for maps, using pairs is the natural approach. Maybe the list of modifiers can be shortened?
• MK: You could call it values for arrays and pairs for maps.
• DN: Pairs on an array gives a very artificial view of an array.
• MK: In many ways, it’s driven by orthogonality: apply all the features for all the data types.
• CG: I think orthogonality is a good thing here. Once we align the function sets with maps and arrays, we may get even more synergy.
• RD: The values and keys accessors are available in other languages.
• DN: I heard what was said about orthogonality. Maybe I agree. Probably it would be more precise to say members rather than pairs. We already talk about members in other places.
• MK: Yes. We don’t have “members” for maps, we have “entries”. There’s a question about whether we could introduce better terminology.
• DN: I wouldn’t object to renaming “entries” to “members” for maps.
• MK: Or just “entries”.
• DN: For arrays, I’m not so sure.
• MK: It would effect a lot of function naming.
• JK: I support values as it stands. It’s a nice complement to pairs and keys. I think many programmers will find that familiar. I also like pairs because it’s not tied to either maps or arrays.
• SF: Usually “members” is associated with object-oriented programming, so I think other names are more suitable.
• DN: I don’t think members are confusing in this case.

Proposal: accept this PR

Accepted.