QT4 CG Meeting 122 Minutes 2025-05-20

Regrets: BTW

• [X] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Dimitre Novatchev (DN)
• [X] Wendell Piez (WP)
• [X] Ed Porter (EP)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW) Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Thanks again to JWL.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is scheduled for 27 May 2025.

No regrets heard.

(Items marked [X] are believed to have been closed via email before this agenda was posted.)

• [ ] QT4CG-082-02: DN to work with NW to come to agreement on the fn:ranks proposal
• [ ] QT4CG-112-01: JLO to propose a concrete example that uses “.” in a ~%method~s.
• [ ] QT4CG-116-01: Add a specific error code for unsupported options on doc and doc-available
• [ ] QT4CG-118-01: MK to make an incorrect type raise an error in #1906
• [ ] QT4CG-119-02: MK to add a note about how schema composition is done for multiple options
• [ ] QT4CG-021-01: MK to raise a new issue which may propose a subset of the QNameLiteral which doesn't permit a namespace.
• [ ] QT4CG-121-02: MK to fix removal of default values in the options for fn:serialize()

This section summarizes all of the issues and pull requests that need to be resolved before we can finish. See Technical Agenda below for the focus of this meeting.

See PR #2001

MK introduces the issue. In supporting multiple sort keys and descending sort keys left us with four rather complex parameters. Let’s put fn:sort back and start over.

• MK: This makes fn:sort a subset of fn:sort-by and it’s defined in terms of the new fn:sort-by function.

MK explains the signature and semantics of fn:sort-by.

• MK: fn:array-sort and fn:array-sort-by are changed in the corresponding way.
• JWL: We now have a trend that where we had complex sequence of arguments, we’re now using records. Are there other places where this is likely to be of benefit?
• MK: Not that immediately come to mind. I have an fn:apply-templates function on the table that uses it.
• JWL: Does it decrease the ability to pick up errors?
• MK: I’m not sure, the type signature says what can be in the record.
• DN: I think that this is a good proposal. In the existing fn:sort function, we had this unpleasant experience that we had to specify an empty collation.
  • … But I got the impression that collation is still before order. It seems to me that collation is the least frequently encountered argument.
• MK: They’re now by name; you can specify them in any order or leave them out if you want.

Some discussion of the use of names vs. positions.

• RD: Would it make sense to define the record as a named record type so we could share it between the two functions?
• MK: It’s a different record for arrays. But, yes, we have a separate proposal about named record types.
• JK: I fear that people will not understand, and will be confused by, fn:sort-by vs fn:sort-with. Do we need both?
• MK: It’s a good question. I think there probably are sorts where defining a comparitor function is easier.
  • … I wouldn’t be a very strong defender of fn:sort-with, but it can be useful.
• JK: Then fn:sort-with needs a more compelling example.
• CG: I think it would be nice to keep fn:sort-with. There was agreement then that it can be helpful to have a comparitor function. With regard to the current proposal, I only have some minor issues.

Some discussion of a sequence vs. a value.

• CG: The examples are pretty much the same as for fn:sort, it might be nice to have examples that highlight the features of fn:sort-by.
• MK: I kept the simple examples to encourage people to learn only one of them.
• DN: I was also a bit confused by fn:sort-by vs fn:sort-with. I think that the difference between the two functions should be more clearly stated.
• JWL: JK’s point about fn:sort-with; I think I’ve used it to sort vectors where it’s very useful to have a comparitor function. Cases where you have big structures that you want to compare bit by bit are the usual case.

Proposal: accept this PR.

Accepted.

See PR #1991

• MK: The trigger for this is that we have test cases that don’t work because we generate test cases that say a function is an instance of its signature and the signatures in the spec use named record types. But they aren’t defined to be part of the static context so you can’t use them.
  • … This PR adds them to the static context.
• MK: In F&O, the named record types are listed in appendix C.
• MK: I did not attempt to review the names of the types or the consistency of they’re definition. The fact that we have them all listed in one place makes that easier.
• JLO: We have six built in record types, but what about all the options. Why aren’t they here?
• MK: That’s a good question. The function signatures don’t have a strict type for the options. But we could define a record type for every options parameter.
  • … But there’s work to be done there.
• RD: This is just adding these names; the machinery to do that already exists through the definition of the static context which references named record types.
• MK: Yes.
• RD: And the syntax within the XSLT and XQuery specs defines record types.
  • … This is equivalent to saying that the static context includes a declaration.
• MK: Yes.
• DN: JLO and I have an action to systemizing the record types in the specifications.
  • … What we plan to do is have an appendix that lists all the option types in an appendix.
  • … I think it would be very helpful to have all the options in the static context.
• MK: Yes, that raises another point. By making these named record types, you also get a constructor function for them.
  • … That should have been brought out more strongly.
• NW: I think it’ll require some work to come up with good names.

Proposal: accept this PR.

Accepted.

See PR #2008

• MK: This is primarily motivated by the fact that I was looking at construction of arrays and maps in XSLT. The most convenient way was to write path expressions. Those became quite long and then you hit the problem of attribute value normalization and you can only use one delimiter.
• MK: What this does is allow you to write expressions in an xsl:xpath instruction.

MK reviews the instruction.

• JWL: Now you get this case where you’ve got something that’s like sequence but in one case the text inside becomes the sequence, but in this case the text becomes an expression. I can see this causing interesting confusion at first.
• DN: What’s the difference between xsl:xpath and xsl:evaluate?
• MK: The difference is that xsl:evaluate allows you to construct an expression from a string.
• DN: Doesn’t that mean I can use xsl:evaluate always?
• MK: Not really, xsl:evaluate doesn’t have access to the static context or the variables.
• DN: I’d like to see a comparison of xsl:xpath, xsl:evaluate, and xsl:transform.
• WP: I’d like to see the comparison expanded. How does this interact with text value templates?
• MK: The xsl:xpath instruction can’t contain text value templates.
• WP: I think it’s intriguing that there’s a difference between this and evaluate. So I’d like to see the examples sketched out more.
• MK: Where this is coming from is that XPath is becoming more and more powerful therefore it’s no longer just for writing one liners. So it’s now inconvenient in XML attributes.
• JWL: If you wanted to do a similar thing with xsl:evaluate, you’d have to put that text in a variable. If you put it directly in a select, you have to do all the quoting.
• MK: You’d also have to pass $title and $author as parameters.
• MK: You want to do construction this way because it looks like JSON, which is what users expect of maps and arrays.
• RD: In the current spec, you’re not allowing nested XSLT constructs like xsl:choose or xsl:if, is there a motivation for that?
• MK: It’s very hard to do. Evan Lenz once had a proposal for allowing XPath and XSLT to be mixed. It’s very hard to define the semantics of that.
• RD: I can see in this example that if you wanted to add a subtitle but its optional, then that becomes fiddlier.
• MK: You can do that with an XPath conditional. What holds you back is apply templates, which is why there’s a separate proposal for that.
• WP: I think you might consider calling this xsl:xpath-literal. I think I’m beginning to appreciate the use case. But I’m concerned about making the use case clearer. The overlap with xsl:evaluate is an issue.
• JK: xsl:select might be a good name.
• NW: I think xsl:select would be a good name.
• DN: I’m confused. Does this xsl:xpath just define the expression or does it also evaluate it?
• MK: It evaluates it.

Some discussion of the name.

• DN: I think that select is a little bit overloaded in XSLT. Maybe find another name.

Some discussion of where it can and can’t be used.

• [ ] QT4CG-122-01: MK to add more tutorial material to xsl:select.

Proposal: accept this PR, with xsl:xpath named xsl:select.

Accepted.

See PR #2006

• MK: This has similar motivation. It’s an XSLT-only function.

MK reviews the PR.

• MK: This gives you the mode as a variable for free. You can also construct parameter names dynamically. I’m a little uneasy, but it’s a bit like functions becoming dynamic. You can adapt.
  • … I have said that the mode must be explicitly declared in the package and it must be public.
  • … Modes aren’t public by default, but if you’re going to do it dynamically you have to.
• JK: What about a call templates function?
• MK: No, because I hate call template.
• WP: This is cool. If you apply templates to “.” can you traverse yourself?
• MK: There’s no default, you have to specify it.
• JWL: Does this cause real implementation problems?
• MK: It does mean that parameter names have to be around at run time, but in practice that’s probably true anyway.
  • … With xsl:call-template you know what template your’e calling, but you can’t do that with apply templates.

Proposal: accept this PR.

Accepted.