QT4 CG Meeting 123 Minutes 2025-05-27

Regrets: BTW, DB

• [ ] 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)
• [ ] Ed Porter (EP)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW) Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is scheduled for 10 June 2025. (The CG will not meet on 3 June).

DB gives regrets.

(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
• [X] QT4CG-121-01: MK to raise a new issue which may propose a subset of the QNameLiteral which doesn't permit a namespace.

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.

We had a couple of meetings discussing the proposal to replace fn:chain with fn:compose. The PR for discussion this week simply removes fn:chain. (In previous straw polls, no one preferred “only fn:chain”; this PR changes the status quo to reflect that.)

I don’t expect there’s a lot of new technical ground to cover here, so we’ll attempt to time box the discussion. Ultimately, I hope the CG can express a clear consensus and that everyone in the minority can accept that consensus.

See PR #1984: 882 Drop fn:chain, and PR #1894: Additional examples to fn:chain

• DN: I don’t think that’s correct. I voted for both, that was not a vote against only fn:chain.
• MK: The PR was a response to the straw poll. People were asked if they wanted chain or compose or both or neither. There were various votes, the one that came out lowest was fn:chain only. That’s the status quo, but there was an unwillingness to confirm that change. So I’m offering the group the simple option of removing it.
• DN: I would first want to apologies on the issue of the PR that we’ve spent so much time on. If we couldn’t decide in four attempts, perhaps the arguments against it are unfounded.

DN shares PR #1984 on the screen

• DN: The arguments against are:
  • … (a) it is more useful to have a function that combines several functions into a single function, without actually applying that function to a set of supplied arguments
    • … I have shown this isn’t true.
  • … (b) The function has special-case behaviour for arrays (if the input is not an array and the function has arity > 1 then the input sequence is converted to an array).
    • … Previously, the argument was different.
    • … The fn:apply function uses an array and has for eight years.
    • … The fn:chain function is adhering to this principle.
    • … And array() is the only data type we can use for this.
  • (c) The need for the function is not clearly motivated; the examples given can all be achieved in some simpler more intuitive way.
    • … The argument that something is “more intuitive” is very subjective.

DN shows some examples. Starting with this from the spec:

(1 to 5) =!> xs:double() =!> math:sqrt() =!> fn($a) { $a + 1 }() => sum()

• DN: I have a lot of sympathy for the end user who has to read or write this expression.
• DN: Doing this with fn:chain is:

let $increment := fn($x) {$x + 1}
return
  chain(1 to 5, (for-each(? chain(? (xs:double#1, math:sqrt#1, $increment))), sum#1)

• DN: This is much more understandable, there’s no repetition of operators. Chain is being used to compose a chain of functions. And because chain is also a function, it can be used in chain.

Some discussion of getting rid of =!>. We decided not to.

• JLO: Why would we just drop fn:chain if we don’t have fn:compose?

NW attempts to explain that the rational is described in the PR and the agenda.

• JK: I initially supported fn:chain but I changed my mind. But I don’t find his example motivating at all. I think his alternative is about 10% longer plus five levels of nesting.
  • … If that’s the sort of thing you like, you can already do that with a function.
• DN: It is just a little bit longer because it saves three operators and we have an mnemonic name.
• NW: I find both of these hard to understand.
• JWL: Because we can’t agree what the signature of a chain/compose function, we aren’t going to have any?
• MK: Yep.
• JWL: That’s kind of sad. If you want to use arrays, you can do that.
• MK: A quick observation on the example. My PR raised three points, one about it’s special case use of arrays. That’s not needed in this example. And it’s better to have something that returns a function instead of applying it. That’s why we have partial application in it. That’s why fn:compose would have been better.
• DN: There are no arrays to be seen here for the user.
  • … The formal definition uses arrays but that doesn’t have anything to do with what the user sees.
  • … Besides it’s main use case, fn:chain also has another use case to do the plumbing regardless of the arity of the function in the chain, which fn:compose couldn’t do.
• CG: I would like to remind us that the numbers of users who will use fn:chain will be very small. Most users don’t use function items at all. Most people will find this irrelevant.
• JLO: The points that MK makes in the PR were the same concerns I had. Users who want to do this can.

Proposal: accept the PR.

• DN: I object. I think people will regret this decision. We still have time to fix it.

Accepted over DN’s objection.

See PR #1959

• MK: The PR still needs a worked example in XQuery. I don’t want to close this until we have.

MK walks thorugh the PR in XSLT.

• MK: I’ve add an option to not construct an implicit constructor from the record type.
  • … Skipping the editorial work of fixing the description of a binary tree.

MK reviews the example in 5.3.3. Example: Defining an Atomic Set.

• MK: It’s interesting that we get a prose description, then a field definition that describes the API, then we get the function definitions. We might want to try to do better.
  • … There’s a field we’d like to make private, but we can’t, so I named it with a leading “_”.
• JWL: This would be just as easy to put this in as a map in XPath, wouldn’t it?
• MK: Yes.
• JWL: This may be an example of a case where using a record doesn’t really help.
• MK: I experimented with various ways, and I agree that xsl:record doesn’t add that much.
• JLO: That’s a complex example that uses “.” in record methods.
  • … Is this meant as an example of the record in XSLT?
• MK: You don’t have to use xsl:record. You could replace it with xsl:map or with an XPath expression that uses a map constructor.

Some discussion of the use of %method in or out of a map or record. MK: there are several options.

• JLO: Using “_” for a semi-private method reminds of JavaScript in the old days.
  • … I would really like to see the merging of the human and machine readable documentation part.
• MK: Yes, one disadvantage of using xsl:record is that we can’t do that, but we could with xsl:map. That might look better.
  • … I’m not sure the XPath way would work any better; the documentation would be in comments.
• DN: This demonstrates the high power we have with methods in records. We’ve also had for more than two years to have a set data type. This demonstration shows that there are no significant obstacles to doing it.
• JWL: To Mike’s point about the documentation, we’ve added xsl:note. We could also add an attribute flavor an @xsl:note attribute.
• MK: Yes, but you couldn’t have structured text in there.
• RD: Looking at the definition of xsl:note, that says it can appear anywhere. So should that be updated?
• MK: The problem is the list of attributes in the definition.

Proposal: accept this PR.

Accepted.

ACTION: QT4CG-123-01: MK to do the set example in XQuery.

See PR #2013

CG reviews the PR.

• CG: We’ve added parse-html and json-doc and parse-json and doc. There are inconsistencies between them I’d I’ve tried to align them. And I’ve added document functions for CSV.
  • fn:parse-xml: Basically the same as before but you can specify binary input.
    • … There were questions about this. But there are cases where binary input comes in.
    • … You can manage that by writing to disk and loading the file, but this is easier.
    • … I think the same arguments apply to fn:parse-html.
    • … The encoding may be embedded in the binary, so you can’t just convert it to a string first.
    • … Mostly the rules have been extended a little. My description of how encoding is detected is a bit vague, but it should be more similar to fn:doc. But that function doesn’t give much detail either. All that fn:doc says is that the data is “parsed as XML”.
• RD: Could we express fn:doc in terms of fn:parse-xml?
• CG: Maybe we could. In many cases fn:doc depends on the implementation.

RD sketches out how it might be possible.

• MK: All the material we have that talks about the dynamic context having a mapping from URIs to resources is something that it would be nice to unify across these functions.
• CG: Right.
• RD: Or maybe we could talk about parsing them into a string.
• MK: It’d be nice to say that the functions are the composition of three functions: getting a resource from a URI, turning a binary into a string, and the parsing a string.
• RD: Or have those as separate sections.
• CG: fn:parse-xml-fragment is similar.
• CG: fn:html-doc is new, it’s an alignment with JSON doc mostly
  • … That description uses some composition.
• CG: We allow binary input to for JSON, similarly, and we add a fn:csv-doc function.
• CG: I haven’t added binary flavors of CSV parsing, but those are all accessible in the XPath. We don’t need to serialize those.
• JWL: Brave to change the fn:doc function given it’s been around for twenty years!
• JK: The one thing I don’t like about allowing binary in fn:parse-xml, I want to be forced to use another function and keep fn:parse-xml() simple.
  • … Are there really use cases to motivate this?
• RD: The use case is, if you have a blob of binary data, detecting the encoding of XML and HTML is complicated. You have to deal with byte order, etc.
• JK: I understand, but why are we putting this in fn:parse-xml instead of some sort of handler function.
• CG: What’s the alternative?
• JK: I’m not proposing one, but I think this muddies the water. If I accidentally send binary data to fn:parse-xml(), I want an error to be raised.

Some discussion of parsing UTF 8 or parsing binary XML.

• RD: With XML and HTML parsers, they accept binary data. So having binary data as an option to these functions let’s you pass the data straight through to those parsers without preprocessing. But I wouldn’t object to separate functions.
• JLO: I am a fan of opening this up. It will allow streaming parsing. I was wondering if the use of new functions (html-doc and csv-doc) that are expressed in terms of unparsed text. Is that good enough?
  • Could parse-csv use binary; then it gets muddy.
• CG: Maybe a “parse binary” option would be good.
• JLO: I’d like to add an option to specify the parser to fn:doc()!
• MK: I think the reasons that the specifications wind up being muddy is that the three operations I described aren’t as independent of each other as we might like. In particular, the encoding detection is done on the fly by the parser.
  • … But I think CG’s proposal is going in the right direction. I think it should just be more explicit that the decoding is delegated to the relevant spec.

Some discussion of whether to accept it or not.

We’ll look again in two weeks.