QT4 CG Meeting 005 Minutes 2022-10-04

Table of Contents


Approved at meeting 006 on 11 October 2022.

Summary of new and continuing actions [0/7]

  • [ ] QT4CG-002-01: NW to incorporate email feedback and produce new versions of the process documents.
  • [ ] QT4CG-003-03: NW to tweak the CSS for function signatures to avoid line breaks on - characters.
  • [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
  • [ ] QT4CG-005-01: NW to update the W3C CG page to reflect the current chairs
  • [ ] QT4CG-005-02: NW to investigate how the function dropdown works and if it’s buggy
  • [ ] QT4CG-005-03: RD to review the variadic functions proposal in #166
  • [ ] QT4CG-005-04: MK to draft a concrete proposal for the range-related functions

1. Administrivia

1.1. Roll call [9/13]

Regrets: BTW, JL

  • [X] Anthony Bufort (AB)
  • [X] Reece Dunn (RD)
  • [X] Christian Grün (CG)
  • [ ] Joel Kalvesmaki (JK)
  • [X] Michael Kay (MK)
  • [ ] John Lumley (JL)
  • [X] Dimitre Novatchev (DN)
  • [X] Ed Porter (EP)
  • [ ] Liam Quin (LQ)
  • [X] Adam Retter [0:06-]
  • [X] C. M. Sperberg-McQueen (CSM)
  • [ ] Bethan Tovey-Walsh (BTW)
  • [X] Norm Tovey-Walsh (NW). Chair. Scribe.

1.2. Accept the agenda

Proposal: Accept the agenda?

  • CMS: I’d like to add an administrivia item about the W3C CG page.

Accepted with that amendment.

1.3. Next meeting

The next meeting is scheduled for Tuesday, 11 October. Any regrets?

No regrets heard. MK may possibly be unavialable.

  • NW: I propose we cancel the meeting if MK is unavailable.

1.4. Approve minutes of the previous meeting

Proposal: Accept the minutes of the previous meeting.


1.5. Review of open action items [4/7]

  • [ ] QT4CG-002-01: NW to incorporate email feedback and produce new versions of the process documents.
  • [ ] QT4CG-003-03: NW to tweak the CSS for function signatures to avoid line breaks on - characters.
  • [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
  • [X] QT4CG-004-01: MK (with DN and RD) to draft a new proposal for variadic functions
  • [X] QT4CG-004-02: DN to make a proposal for deep-equal-safe for future discussion
  • [X] QT4CG-004-03: MK to draft a pull request implementing fn:intersperse
    • See below.
  • [X] QT4CG-004-04: DN to open an issue for the inverse of fn:intersperse
    • DN withdraws the suggestion.

1.6. W3C CG Page

  • CMS: I notice that the list of chairs has not been updated on the W3C CG page.

ACTION QT4CG-005-01: NW to update the W3C CG page to reflect the current chairs

2. Technical Agenda

2.1. Approve PR #163

This PR completes Michael’s action to draft prose for fn:intersperse.


  • DN: There seems to be some issue with the drop down. On the main spec page where this hasn’t been adopted, there is a dropdown that doesn’t go anywhere.

ACTION QT4CG-005-02: NW to investigate how the function dropdown works and if it’s buggy

2.2. Variadic functions

We had a good discussion of this last week and there has been plenty of activity since. This item is to check with the group to see if there issues that would benefit from immediate discussion or if the proposals are still proceeding apace.

  • MK: I ‘d like to get the proposal that I did against #166 reviewed and accepted, then consider the amendments. I haven’t had much feedback on the proposal as it stands. If folks need to be talked thorugh it, i’m happy to do that.
  • RD: Haven’t looked at it in depth, I’ll take an action to do that.

ACTION QT4CG-005-03: RD to review the variadic functions proposal in #166

We’ll review this proposal next week.

  • DN: I have the feeling that we made good progress on one of the issues. I’d like to see it reflected in the proposal. In particular, how to represent what was called sequence variadic calls. I think we finally came to an agreement, but I’d like to see it in the spec.
  • MK: That’s a subsequent proposal. CMS proposed splitting it into parts and I think that was a really good idea.
  • NW: Is that ok with everyone?
  • DN: Yes. We’re just talking about the very first part.
  • MK: the first part defines default values for function parameters in XQuery and XSLT; defines the ability to do function calls in XPath with keyword arguments; and picking up the defaults when you the bind them. It does that for static function calls and static partial applications.

2.3. XPath 4.0 functions

Based on offline conversations with MK, the order of functions in this list has been adjusted with a goal of giving priority to things that (a) should involve less discussion and (b) should involve less editorial work.

2.3.1. fn:replicate

  • See https://qt4cg.org/specifications/xpath-functions-40/Overview.html#func-replicate
  • MK: I think this is already in the spec, we’re just looking for approval.
  • AR: Not picking on this function in particular, but in a general sense, what is the use case for this? Where are the use cases documented? In the case of this particular function, I wonder when would I ever use it? The values it’s replicating are immutable, so why not just stick it in a variable?
  • CG: One example is if you want to have 100 dashes. You can make that with string-join and a loop, but this is more convenient.
  • MK: Or filling out blank entries in a table.
  • CMS: This could be regarded as syntatic sugar for the loop, but for the implementation, it’s faster. I was assuming implementors would manage the internals of this differently than a loop.
  • CG: It’s also something that comes from functional languages. A chain of functions can, for example, just add an fn:replicate in the middle without restructureing the query to get a loop.
  • DN: From my perspective, I would put this in a group of “convenience generator functions”. We could have many of them, and they’re very useful.
  • AR: Having heard the use case, I understand the purpose of it, but I had a hard time from just the specification. Are the use cases documented somewhere?
  • MK: Usually in the GitHub issue that proposed it.
  • EP: Perhaps adding a more complicated example would help?
  • RD: I was going to say that too.
  • NW: We’re going through a backlog developed and spec’d over a couple of years. When we get through this, I expect we’ll more consistently be discussing specific issues where the use cases will be more obvious.
  • CMS: I was going to propose to make an action to be sure the relative GitHub issue has a fairly clear statement of the use case, but maybe there isn’t one.
    • … It’s extremely useful if a group creates a use cases and design document; I’d like to find a place to ensure that all of that is clear.
    • … Adding examples to the spec can be useful but it is seldom the only place
  • DN: Do we have a replicate function for strings, what about a similar function not for sequences but for arrays? And to address what CMS said; I’ve been asked for use cases, and I’ve often referred to databases for inspriation. Ideally we could have a collection of documents and examples based on them. We could even tie them into one of the online evaluation frameworks like Martin Honnen’s XPath Fiddle.
  • RD: There’s an XQuery requirements and use cases document. Would it make sense to write one for XPath and XSLT 4.0?
  • NW: Yes, but it’s a lot of work. Who’s going to do it?
  • MK: An explicit requirements and use cases document helps sometimes in closing down work. Documenting the whole set of ideas can help manage the open-endendess of a project like this.
  • AR: I’d be happy with the answer that there be more examples and use cases in the GitHub issues and a link back to those.
  • MK: There’s a dependency here on being able to pass “3” as a non-negative integer.

Some discussion of whether or not negative numbers make sense, but the focus of MK’s remark is about what happens if we do leave it as it is.

  • NW: Leave it open?
  • MK: No, I was just observing the forward dependency.
  • CMS: Either we accept the downcasting proposal later or we’ll have to come back and change this?
  • MK: Yes. I’ll put a todo in the spec to point out this dependency.

Proposal: Accept fn:replicate


2.3.2. The family of functions proposed as fn:range-from/fn:range-to and others

What approach should we persue in tackling this family of functions?

  • MK: These reflect various iterations of my thinking on this. I’m welcoming feedback on exactly how this functionality shoud be packaged. The use case is to deliver the part of a sequence before or after some predicate: “find the paragraphs that precede the first H2 element” or somehing more complex with attributes. That’s remarkly hard to achive without higher order functions (HOF). But now that we have HOF, it’s much easier. But that still leaves the question of how to package it.
    • … Four functions: fn:items-before, fn:items-after, fn:items-from, and fn:items-until does it one way.
    • … Or we could do it with two functions with include/exclude options
    • … Or even with one function with options
  • MK: Do we agree it’s useful?
  • AR: Am I right that these are convenience functions we could write with window clauses?
  • MK: We don’t have window clauses in XPath and not having it in a function makes it harder to use in functional ways.
  • CG: You also can’t interrupt a window clause; with the function you can shortcut the implementation.
  • CMS: FWIW, my first instinct is to think, if we merge them all into a single function with parameters, then it turns into the equivalent of the do/for/while loop constructs in some languages with more different options and syntactic variations than I was ever able to learn. So my gut instinct is: no, four is a good number!
  • NW: I agree; I’d be happy with four, and probably happy with two, but not one!
  • DN: I agree; I’d prefer ot have four functions. These are a convienience. Because I’m not a native speaker of English; I have some trouble with the names. I’d prefer items-starting-with and items-ending-with.
  • NW: That sounds reasonable to me
  • RD: In the notes, there’s a combined range-from and range-to function, so I think that would make sense. To have a function that accepts both a from and a to. It’s going to be clunkier to write it as two separate founction calls.
    • … But as to the combinations, that would be better as separate functions
  • MK: So you want range-between?
  • RD: Yeah.
  • MK: That has all sorts of complexities, such as what happens if the end comes before the start. It’s not difficult to compose them is the conclusion I came to.
  • CMS: I agree with RD, but that’s because I don’t tend to use the ! as a composition mechanism and maybe I should learn.
  • NW: I hear consensus for having them, and for having four functions.
  • CMS: What explicit names are we discussing?
  • NW: I think MK asked for advice. We should let him take this as advice.

ACTION QT4CG-005-04: MK to draft a concrete proposal for the range-related functions

2.3.3. fn:duplicate-values

  • See https://github.com/qt4cg/qtspecs/issues/123
  • CG: We talked about all-equal and all-different functions recently. We’ve noteced that there are many cases where you want to know which values are the duplicates. This is the opposiate of fn:distinct-values. You can do it with a loop, but this provides a functional way to do it.
  • MK: I wonder, if you’re in an XML world where you’re looking for element with, for example, duplicate attribute, if you might not care that the surname “Kay” is duplicated, you might want to get the elements that posses them. Rather like highest and lowest, putting in a function to find the elements that have duplicate values might be more useful.
  • CMS: As long as there’s a relative straight-forward default, …
  • MK: The default can be the identity function, then you get exactly this.
  • RD: This would be adding a key as third parameter like highest and lowest?

Some discussion of this idea. And a review of the comments on the issue.

  • CMS: On 10 Oct, passing a comparison function comes up.
  • DN: I wanted to ask about this. From this description, I don’t see any case where the function would rasie an error. That’s good. But if we have a function, like the eq operator, for example, then it could raise an error. That would have to be added to the description. Definitely it would be good to provide a comparison function.
  • CG: Maybe if you rewrote the function, the result would probably be more complex. If you wanted to return the original values, it often makes sense to group them in some way. It might make sense to return a map or a sequence of arrays…
  • MK: That’s true, it does add to the complexity quite a bit.
  • CMS: I’m taken by Adams suggestion that these are variations of a filter functions, should we start ehre?

AR in Zoom chat:

  • AR: A lot of these functions to me seem to be basically variations on a fn:filter($sequence, $start-fn, $end-fn?)
  • AR: Would it be better to add the more generic Higher-order-functions to our spec, and then perhaps add convenience functions around these to FunctX or similar?

(Some discussion of whether these were, in fact, comments on duplicate values or the previous topic.)

  • AR: I think CG’s function could also be implemented in terms of fn:filter, if we had such a thing. You could have a predicate that determines what “duplicate” means.
  • CG: That’s more like a grouping function. I’m not sure what you’d do with filter if it had duplicates.
  • MK: Filter only looks at items one at a time, where this is looking at groups of items.
  • RD: It’s like group by.
  • AR: But perhaps it still makes sense to think of these in terms of higher order functions that we need.
  • CG: A function like fn:until. I thought some of the items before and items after functions could be implemented with that. In another way the item functions are more generic. Like while/until in an imperative langauge.
  • DN: Two things: because the issue of comparison functions is going to come up again and again, maybe we need to think about moving the question of a suitable comparison function higher in the agenda. The other thing is that I’m not sure we should spend so much time talking about possible implementations. This is about recognziing the value of the function; I don’t think we should impose an implementation. We should just accept well defined functions that we agree are useful.
  • CMS: I agree with DN in principle, but I’m worried by one thing. To take a concrete example, in XSLT 1.0, there’s a key construct and it adds no functionality and doesn’t add any great deal of convenience. So I never use it. I leave it in stylesheets that I’m editing or updating. I only use it if I find a performance issue that I need to resolve. So it only exists to allow implementations to make something that’s commonly used run fast. We should avoid boxing in or constraining implementors, but key doesn’t constrain them. As an implementor, it’s obvious how to use it and why it’s valuable. As a non-implementor, I don’t always find those things obvious, so I wouldn’t want to prevent all discussion of implementations.
  • RD: I was just going to say, it can be useful in the discussion to identify other higher level functions that we haven’t considered.
  • NW: We’re running out of time. It sounds like the question of whether or not this function takes a comparision function as an argument is something we can take to email or the issue comments. We’ll pick up here next week.

3. Any other business

None heard.