QT4 CG Meeting 028 Minutes 2023-03-28

Regrets: EP

• [ ] Anthony (Tony) Bufort (AB)
• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF) [0:15-]
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [0:25-]
• [X] Michael Kay (MK)
• [X] John Lumley (JL)
• [X] Dimitre Novatchev (DN)
• [ ] Ed Porter (EP)
• [ ] C. M. Sperberg-McQueen (MSM)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW). Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

• MK: Maybe put issues on the list, not just PRs.

Perhaps the composite language for path language for next week? Issue 350?

• JL: Keep track of how many issues and PRs are open/closed.
• DN: Maybe also mix them, so that we don’t discuss all the proposals from the same person.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is scheduled for Tuesday, 4 April 2023.

No regrets heard.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
• [ ] QT4CG-016-08: RD to clarify how namespace comparisons are performed.
• [ ] QT4CG-023-01: NW to review the stylesheets for functions across XPath and XSLT
• [ ] QT4CG-025-03: MK to revise and expand technical detail in PR #375
• [X] QT4CG-025-04: RD to remove the note in 15.5.15 of functions and operators.
• [ ] QT4CG-026-01: MK to write a summary paper that outlines the decisions we need to make on “value sequences”
• [ ] QT4CG-027-01: MK to update the text for next-match wrt type() matching

See PR pull request #408

• MK: Makes explciit that you can’t have two fucntion siwht the sam ename
• RD: Do we need to handle special handling for XSD 1.1.
  • … You could have the case where you’re declaring a name that clashes with 1.1
• MK: The XML Schema namespace is reserved anyway.
• DN: Maybe we could have predefined namespaces where users cannot declare their own functions.
• MK: That would be backwards incompatible; we already allow you to use the same namespace for types and functions.
• DN: Maybe we could define a convention for this.
• MK: We do have reserved namespaces; this is question of whether users can use the same namespace for types and functions.

Some discussion of the scope of this error. This is about user defined types and functions, not system ones.

• CG: Will it be possible to use keyword argument syntax with type constructor functions?
  • … Can you use the keyword argument syntax?
• MK: We already have the rule that you can’t have two functions with the same name and arity, this proposal is just clarifying that case.

Some discussion of keyword argument syntax. The name of the argument to constructor functions is defined to be value.

• DN: What namespace are the constructor functions in?
• MK: They’re in the namespace of the types.

Some further discussion of the practicality of reserving namespaces to prevent users from defining types or functions.

Proposal: Accept the PR

Accepted.

See PR pull request #406

• MK: The spec includes a draft for an xsl:array instruction in XSLT. The complication is that with xsl:array you want to be able to define any array including ones where you can have empty sequences or other sequences, and this isn’t very compatible with sequence constructors.

MK reviews xsl:array, section 22.1 of the XSLT spec.

• MK: The use attribute lets you do construction and deconstruction in a way similar to the array functions. This seems like a much more suitable way to construct arrays in XSLT.
• JL: In the map case, we have xsl:map-entry, why doesn’t xsl:array-entry work?
• MK: You could do that, but you’d lose the ability to build arrays using any kind of values. This makes the construction conventions a matter of code style rather than baking them into the language.
• RD: Would it make sense to introduce parity on both sides? Have xsl:array-entry for arrays and a use attribute on maps?
• MK: The most common use case by far is that the array consists of a sequence of single items.

Some discussion of how the behavior of the construct shouldn’t depend on its content because you might want to, for example, refactor the content into an xsl:apply-templates.

• RD: With array:members, you get a sequence of singleton maps.

Further discussion of how xsl:array-member wouldn’t actually encapsulate the result because you can’t distinguish them by type.

• DN: Let’s say I want to use xsl:array, is there anything I can do that I can’t do in pure XPath?
• MK: In the use cases I’ve done, I’ve found it very awkward to mix the XPath approach with apply templates.
• DN: It would be valuable to post that use case. Couldn’t we do this by making a map with sequential integer keys and then have a cast instruction of some sort?
• MK: Well, you don’t want to have to allocate the numbers by hand. Consider the first example, you wouldn’t want to allocate numbers for each string. Consider the second example, it answers both of these questions.
• JK: On the bandwagon about parity with xsl:map and xsl:map-entry. Can you apply-templates with an array instruction to populate it with members in other templates?
• MK: It’s supposed to make that possible; those were the use cases I had in mind.

Proposal: Accept the PR

Accepted.

See PR pull request #404

• MK: This entirely editorial. It fixes a trivial error in fn:tokenize and updates the change history.

Proposal: Accept the PR

Accepted.

See PR pull request #375

• MK: I have an open action; we can’t progress this right now.

See PR pull request #396

Mike describes his attempt to address no failure use cases for deep-equal.

• MK: If you have two function items that aren’t arrays or maps, then you use the existing rules for determinism. This relies on prose already in the 3.1 spec.
  • … One of the preconditions is that the processor is able to determine that they’re the same and that’s implementation defined.
  • … You can always return false, but the note outlines some of the cases where it might make sense to return true.
• RD: If I understand correctly, if you have the example that the processor knows that you’re referring to the arity 1 version of fn:name in both cases, then it must or might return true?
• MK: It’s not required. It’s quite difficult to codify. Partial function application and context come into play.
• RD: I’m not suggesting this for the case of partial function application. That’s a special intermediate function. I mean in the case where you know you have the arity 1 fn:name in both cases.
• MK: Even if it’s the identical expression, you have to make sure that the context is the same. You might have the same variable reference but the static context is different in one case.
• DN: I really respect the effort here, but all these debates can be avoided and they show that trying to define these things is hard. This could be much easier; just assert that all functions (except maps and arrays) are the same or different (as we did for NaN or INF). I don’t care, I don’t think these use cases occur in practice often enough to worry about.
• MK: Part of the problem is that we use fn:deep-equal in other contexts. For example, suppose that you use it for sorting or grouping. Then if it doesn’t have clean semantics, for example if every item is equal to itself, then it isn’t appropriate for some of those cases.
• DN: Then we need a new function fn:error-free-comparitor that has the semantics we need.
• MK: That’s what this is trying to do.
• DN: I would be happier with just a new function.
• MK: Wouldn’t that just move the problem to that new function?

Some continued discussion of how this could work.

• SF: When we’re talking about function comparison, what is different in the different use cases? One comaprison of functions is about casting values. Another case might be trying to decide which function to call. So those are different use cases. In JS there’s an analogy between “==” and “===”.
• MK: We’re not using doing this because there’s a use case for comparing functions, but there’s a use ase for having a function that compares anything without failing and has nice properties like reflexivity and transitivity.
• SF: That’s just going to raise the issue later with caching, etc.
• JL: I like this; it’s going to be to some extent implementation dependent. The early things are easy to compare, but later on it gets harder and you can just return false.
• DN: I think JL and I are in complete agreement.
• JL: I’m not actually sure I am agreeing; this looks pretty good, we don’t need to go any deeper than the first few items on the list. This doesn’t raise errors and it’s pretty easy to implement. You can stop whenever it gets too deep.
• DN: That’s what we agree on, we shouldn’t go deeper. I think we don’t need to go deeper at all. We need a use case where precise comparisons really matter. I’m not convinced there are any.
• JL: I thought that NaN was the one thing that isn’t equal to itself.
• MK: In deep equal it is.
• DN: Exactly. Everyone knows that NaN != NaN, but we decided that it would be equal in deep equal. So we can make the same arbitrary decision about functions.

Some discussion of what does or doesn’t constitute the property of NaN vs the property of functions.

Some discussion of how we can minimize surprise to users. Not all languages follow IEEE specifications for comparing things like NaNs and infinities.

• RD: On the one hand it is arbitrary, but on the other we aren’t just making things up. Saying that two function references that you know are different are in fact equal goes against a users expectation.
• DN: But the same is true of NaN!

See PR pull request #368

• MK: I have an open action; we can’t progress this right now.