QT4 CG Meeting 005 Minutes 2022-10-04

• 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

Accepted.

• fn:range-from, https://qt4cg.org/specifications/xpath-functions-40/Overview.html#func-range-from
• fn:range-to, https://qt4cg.org/specifications/xpath-functions-40/Overview.html#func-range-to
• fn:items-before, fn:items-after, fn:items-from, and fn:items-until
  • Unspecified, see https://qt4cg.org/specifications/xpath-functions-40/Overview.html#new-functions
• See also #149: functions for splitting a sequence (or array) based on predicate matching
• Also related: fn:slice, https://qt4cg.org/specifications/xpath-functions-40/Overview.html#func-slice

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

• 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?

(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.