QT4 CG Meeting 113 Minutes 2025-03-11

These charts have been adjusted so they reflect the preceding six months of work.

The following PRs are open but have merge conflicts or comments which suggest they aren’t ready for action.

• PR #1766: 1715 Drop array bound checking
• PR #1735: 1341 Drop $position callback from many functions
• PR #1587: 557 Add fn:binary-resource
• PR #1296: 982 Rewrite of scan-left and scan-right
• PR #1283: 77b Update expressions
• PR #1227: 150 PR resubmission for fn ranks
• PR #1062: 150bis revised proposal for fn:ranks

The following substantive PRs were open when this agenda was prepared.

• PR #1740: 1725b Further elaboration of duplicates handling in maps
• PR #1778: 1456 Lookup expressions filtered by type
• PR #1819: 451 Multiple schemas in XSLT
• PR #1856: 998 Add boundary and lookahead/behind assertions
• PR #1858: Initial xsl:record

See PR #1735

Straw poll:

• (a) drop the position callback on fold-left/fold-right
• (b) add the position callback to scan-left/scan-right
• (c) drop the scan-left/scan-right functions entirely

(a): 4 (b): 1 (c): 3

Proposal: drop the position callback on fold-left/fold-right

Accepted.

Proposal: drop the scan-left/scan-right functions entirely

There are some objections.

• DN: I think running totals are a use case for the scan functions. And I have some other use cases.
• NW: Can you send them in email or add them to an appropriate issue or PR?
• JWL: Can the scan-left and scan-right functions be written in XPath?
• CG: Yes, you can use fold-left and fold-right, but it’s a bit more sophisticated use.
• JWL: Okay, but if it’s an uncommon requirement, that might be okay.
• CG: I think we need some reasonably intuitive use case for scan-right. And we’d need to add the array equivalents as well.
  • … Do we really want four functions for this feature?
• DN: I’m happy to make a PR. We have both sequences and arrays, but it’s not specific to the scan functions.
• MK: I think we need to start to become a bit more disciplinarian about proposals for things that don’t have any test cases.
  • … I think we need to move to a position where we don’t accept things without test cases.
• DN: Can the examples be made tests?
• MK: Yes, but test cases need to cover all the edge cases, where the examples don’t.
• JLO: Could we reach out to the broader community to find out if the scan functions are needed?
• CG: We’ve had a scan function for maybe ten years, but I’ve never seen anyone use it. But maybe they would if it had been in the main spec.
  • … But the right version has never been used.

ACTION QT4CG-113-01: MK to make a PR to drop the position callback on fold-left/fold-right

See PR #1740

• MK: This is an attempt to make duplicate handling more consistent. Thanks to CG or one of his users for the recommendation.
• MK: We now have an options map on fn:map-build with a combine option.
  • … There are some string options, or you can provide a function to do it.
  • … So three functions in F&O
• MK: In XSLT, there are a few similar changes.
  • … on-duplicates becomes duplicates
  • … Similar changes and a few other corrections.
• DN: I think a “drop-both” keys option would also be useful.
  • … If we have two sets, we can have union, difference, or the symmetric difference
• MK: It’s a bit harder to integrate, but it could be made one of the text options.
• NW: DN, can you make an issue for that?
• JLO: Isn’t that just a function that returns the empty sequence?
• MK: No that would give you the empty sequence as the value, not remove the key!

Some discussion of the semantics of the function and why “drop-both” can’t be implemented with the function.

• DN: If the function had different results: accept-first, accept-last, combine, or drop-both, that would work.
• MK: Let’s park that as a new suggestion.

Proposal: Accept this PR.

Accepted.

See PR #1778

• MK: I abandoned #1778 and made a new PR to work around some merge conflicts.

See PR #1864

• MK introduces the PR.
• MK: Most of the use cases I’ve seen are where you want to select a record type.
  • … KeySpecifier now allows a TypeSpecifier
  • … The reason for using the tilde syntax is that the longer form becomes very unwieldy in more realistic examples.
  • … Generally, if you’re processing deep selection into JSON structures, the way that you select which things you’re interested in, unlike XML you don’t have a name, you identify them by content instead: “all the records that have a ‘to’ and ‘distant’ field”, for example.
  • … Or refer to it by name if it has one.
• DN: I think the ~ symbol is makes the syntax even more cryptic.
  • … I propose that we don’t use a symbol for this, we can have a function “of-type” that very clearly shows what is being done.
  • … Also, ~ typically means “approximately the same”.
  • … If we accept this PR, then we will have the problem of not being able to distinguish between empty sequence values and a missing value.
• MK: The second point is completely orthogonal. This PR doesn’t change that at all.
  • .. The choice of symbol is constrained by the fact that we can’t have an NCName after the question mark because that selects a field of the map. We have to have some syntax there that isn’t currently allowed, that’s why I chose a new symbol. I think we could extend the use of ~ to mean an instance of operation and I find it a good choice of symbol. It’s a bit like “@” for attributes in that “~” and type have some phonological connection.
    • … ~ has a very wide range of uses; saying it’s a kind of “x” is certainly one of those uses.
• JWL: Are we allowed to have a record type who’s name is “record”? Wouldn’t that introduce an ambiguity, potentially?
• MK: Is this specifically related to ~?
• JWL: Yes.

Some further discussion of the various flavors of ambiguity that might or might not be ambiguous here. Scribe concludes “probably not.”

• JLO: I think these are valid points; I like this, but there was a “pairs” thing in some of the examples.
• MK: Yes, the modifier, ::.
  • … But this is logically part of the key specifier, not part of the modifier.
• JLO: I don’t have a big problem with ~, but it would be nice to have something more explicit.
  • … What happens if I select a thing that has additional attributes?
  • … If it’s not a named record?
• MK: Only if you specify , *.
• JLO: Yes, then I really like it.
• DN: If we can’t use a name, and I’m not convinced we can’t, but having a single character to specify this is very error prone. I’d prefer to have something longer and more visible, perhaps three *. I like that better than ~.
• MK: I sort of feel like the more punctuation characters you have there, the more likely users are to get them wrong.
• DN: It’s very unlikely for someone to type three * if they didn’t mean that. It’s very visual.
• MK: Unfortunately, “*” is grossly overloaded already.
• MK: I’ve gone around in circles a lot of times to find a better syntax. I’ve tried lots of things and they either raised ambiguities or were confusing.
• JK: I support ~, I find it clear and I have the opposite reaction to DN.

Proposal: Accept this PR.

Accepted.

See PR #1858

JWL introduces the PR.

• JWL: This is basically a shortcut for forming up a map.
  • … There are two attributes in the xsl: namespace, we’ll come back to that.
  • … xsl:record basically takes attributes that form the map.

JWL walks through an example.

• JWL: It only works when the keys (attributes) are xs:NCNames.
  • … The values are evaluated as expressions.
  • … We can define xsl:record in terms of a source transformation.
  • … The problem is the xsl: qualified names.

JWL outlines the problem with “as” and “duplicates”: are the controls for the map or are they entries?

• JWL: One option might be to put the options in a special child in the xsl:record.
  • … Note that duplicates is only necessary if you have a sequence constructor.
• NW: I was enthusiastic, but my enthusiasm crashed on the attributes.
• MK: I think we need something to describe extra attributes in the syntax summary.

ACTION QT4CG-113-02: NW to investigate a way to show extra attributes in the syntax summary.

• MK: I think we should say the values are coerced.
• MK: I think we should go either with a child element or the namespace qualified names.
• JWL: That’s almost as ugly.
• MK: Probably need to say something about shadow attributes. Simplest thing is to say there aren’t any.

ACTION QT4CG-113-03: JWL to consider shadow attributes and all the other standard attributes on xsl:record.

• JK: My initial question was going to ask how this hooks up with named records.
• JLO: Two questions, why is the xsl:as defaulted to map, what else would it be?
• JWL: Well it might be a named item type…
• JLO: For duplicates, what does ‘expression’ mean?
• JWL: The default will be an expression or one of a set of strings. The default is a function that throws an error. It’s exactly the same as on fn:map-merge etc.
• JK: It’s worth mentioning that you may need some words about type conversion.

JWL will revise for next time.