QT4 CG Meeting 002 Minutes 2022-09-13

• NW: I thought what came out of the email discussion was really good. I suggest we adopt that for the time being, we can always change it as we go.

ACTION QT4CG-002-03: NW to setup the GitHub labels as discussed in email.

• MK: I think there should be two signatures.
• RD: Doesn’t the second example need to be fn:boolean#1?
• MK: Yes. Thank you.
• MK: The same logic applies to the first one which I was struggling with.
• CSM: Question: am I right to think this is extensionally equivalent to every $i in input…
• MK: That’s what the rule says (…points to the rule in the spec…).
  • CSM: I missed it. I propose that the rule should be a code block, not inline code!
• CSM: This is just syntactic sugar for brevity?
• MK: Not just for brevity. In a world of higher order functions, it becomes useful to have functionality encapsulated in a function. You can use this as an argument to array-filter, for example.
• CSM: Now I’m puzzled by the signature returns xs:integer

Agreement that it should return xs:boolean.

• DN: Maybe it would be good if there is a function like this for arrays.
• MK: Yes, as a general issue, should we have array functions corresponding to every sequence function.
• DN: I think it would be good so we don’t have to explain the distinction.

ACTION QT4CG-002-06: DN to make a GitHub issue to track the question of whether we need array versions of all functions that take sequences.

Some discusssion of what namespace these are in.

• MK: I’ve used a bit of syntax in the examples that we haven’t approved yet. That might be a bad idea.
• RD: I think it’s fine to keep it for now, if the syntax changes, we’ll have to fix the examples.

Proposal: add fn:all to the consensus draft?

No objections.

ACTION QT4CG-002-07: MK to make a pull request incorporating the changes to fn:all.

ACTION QT4CG-002-08: NW to investigate automatically generating formatted specs from pull requests.

• MK: This is very similar to fn:all
• DN: Are we going to provide implementation hints?
• MK: I think those are general rules.
  • We do often provide a sample implementation in XQuery or XSLT or both.
• NW: Are we going to try to do that for all the functions, or only where it provides extra clarity?
• MK: I think we’ve tended to do it where it adds clarity.
• DN: I think this would contribute to the clarity.
• CSM: If I understand correctly, DN is suggesting that we have code not to clarify the semantics of the function, which are given fairly explicilty by the rule, but to clarify that an implementation is allowed to short circuit the evaluation?
• DN: No, those are two separate things.
• JL: In both these examples, we have exactly that in the rule. You could write this yourself if you were allowed to write a function in the fn: namespace.
  • What is of interest to me is what happens if you have an error later on.
• MK: Error handling is defined by general rules for XPath. We don’t like them, they’re horrible, but they exist!
• DN: One more benefit is that it would ease testing. It can serve as an oracle for testing.
• NW: Can we try it out and see what we think?

The scribe missed some description of what a potential implementation might look like, for fn:all?

• MK: The danger of providing a recursive implementation is that it would appear to invalidate a parallel implementation. It would have to be non-normative.
• NW: Right, so the examples are sometimes more confusing.
• CSM: I put this in chat: function($input, $predicate) as xs:boolean { every … } anything beyond that?
• DN: I don’t understand what you’ve written.
• CSM: If you asked me for a sample implementation, I’d write what I’ve given above.
• DN: Yes.
• CSM: So the question in my mind is, is that all you wanted? I’d be happy with the rules as they are, but if the point of this is how to get from an expression to a function would work. In that case, it could be normative.
  • I take MK’s point, you don’t want to make the sample/reference implementation more specific than it should be.
• DN: We just provide one implementation, we will not say that it is the normative implementations.
• MK: The constraints on error behavior can also be different.
• DN: In any case, I think it’s preferable to have it.
• RD: I was going to say in this case where it’s trivial, I don’t think adding an implementation adds clarity. But it would make sense in more complicated.
• NW: I think that comes back to my question earlier, it makes more sense when the functions are complicated. And DN is right, if the example implementation is too complicated that’s going to help us understand that maybe we’ve specified the function poorly.
• MK: I’d forgotten that there are cases where we define it normatively. I have no objection to using the same style.
• EP: Yes, we’re almost there in the rules. The spec is in the rule, we’d just have to wrap it in function and we’d be done.
• AB: Doing it for examples where it’s complicated makes more sense to me than doing it all the time.
• BT: There’s one argument for doing for everything where you think it’s very simple but the explanation makes you think maybe it’s more complicated.
• MK: You can’t give example implementations for all functions.
• NW: Let’s go with adding them when it adds clarity.
• MK: I’ll try to use the spec style and we can

Proposal: add fn:some to the consensus draft?

No objections.

ACTION QT4CG-002-09: MK to make a pull request incorporating the changes to fn:some.