QT4 CG Meeting 114 Minutes 2025-03-18

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 #1283: 77b Update expressions
• PR #1062: 150bis revised proposal for fn:ranks

The following PRs are editorial, small, or otherwise appeared to be uncontroversial when the agenda was prepared. The chairs propose that these can be merged without discussion. If you think discussion is necessary, please say so.

• PR #1880: Editorial revision of fn:function-identity
• PR #1878: 1851 Make ?variety optional; explain namespace-sensitive
• PR #1875: 1861 Params passed automatically through next-match
• PR #1873: 1869 duplicate values

Proposal: Merge without discussion, except for #1875

Accepted.

It has been proposed that the following issues be closed without action. If you think discussion is necessary, please say so.

• Issue #1863: add \U \u L \u \E to replace() (case conversion)

Proposal: Close without any further action.

Accepted.

See PR #1877

I was tempted to mark this one merge-without-discussion, but let’s see if we all agree on the proposed syntactic change.

Proposal: Accepted.

See PR #1882

I was tempted to mark this one merge-without-discussion, but there’s an open comment on the PR (but not an especially substantive one, AFAICT).

• MK: I thought that scan-left and scan-right should be in the same style.
• CG: The simple map operator doesn’t have a formal equivalent.
• MK: Yes, reducing the number of constructs is usefull

Some discussion of other primitives; we’re using for-each a lot.

• MK: Aspirationally, I’d like to get the equivalents to be on primitives in the data model.
• DN: Speaking of primitives; for-each can be expressed using fold-left or fold-right.
• MK: Or recursion.

Proposal: Accepted, without futher edits.

Accepted.

See PR #1879

I was tempted to mark this one merge-without-discussion, but some brief discussion of entity-expansion-limit may be in order.

• MK: I did a revision in the light of the comment on entity-expansion-limit.

MK reviews the options on fn:parse-xml().

• NW: Expanding an external entity can change the base URI for entities within that entity…but I don’t think anyone is likely to misread that.
• NW: Many XPointer schemes aren’t supportable by a streaming implementation in the parser.
• JLO: What do you do if you have an override? Is it then an error?
• MK: I think we should leave it up to the implementation.
• WP: Thank you, this is awesome. Point of clarification, numeric character references are also allowed (even if entity expansion is allowed).
  • … It might also be nice to have some examples.
• MK: There’s always room for more tutorial material.
• RD: Should we put a note in about potential security issue? One of the reasons to limit entity expansion is to prevent malicious “billion laughs” attacks.
• NW: I’m reluctant.
• WP: I don’t think we should explain how to attack the parser.
• RD: A caution on setting the limit too high.
• CG: I would agree that if you’re looking for entity expansion limit on the web, you’ll find lots of answers.

Proposal: Accept this PR.

Accepted.

See PR #1856

MK introduces the PR.

• MK: This PR basically replaces the whole regular expression section with a new one.
• MK: We now have a processing model for regular expressions that allows us to define some terms.
  • … Some attempt to standardize terminology for capture groups and capturing subexpressions.

The rules for regular expression matching in different libraries are often incompletely specified. It’s possible that the rules here aren’t precisely the same as other libraries.

• MK: The constraint on lookbehind is stronger than some, but it means you don’t have to backtrack.
• MK: The flags are unchanged; the semantics of some of the functions has been clarified.
• MK: Functions like fn:tokenize() now allow the regular expression to match a zero-length string and define rules for what it means.
  • … It’s common to split a string into characters if the regex matches the zero length strings. But, again, there’s lots of variation in the libraries.
• RD: Do we specify a minimum version of Unicode? That will effect what the character classes match and what languages are available.
• MK: I think we recommend implementations to support the latest, but we don’t impose any constraints.

Some discussion of whether we should impose a constraint.

• RD: Would it be worth adding a note that the Unicode group matching is dependent on the version of Unicode.
• MK: We probably get some of that from XSD 1.1.
• JK: I’m grateful, this must have been a lot of work.
• JLO: I really like the changes; my only question is what lead to the decision to split on space instead of between characters when the string is a zero length.
• MK: That’s not new; tokenize with no regular expression was already defined in 3.1 to split on space boundaries.

Some discussion of how to split; the empty string will work.

• RD: Could the grammar be written in the same style as the XPath 3.1 grammar?
• MK: Yes. The semantics of having more than one grammar might be a bit tricky.
• RD: Don’t we have that with XSLT?
• MK: No, there’s only one grammar in the document.
• JWL: Where is the other grammar in F&O? The grammars for XPath don’t appear in here.

Proposal: Accept this PR.

Accepted.

See PR #1867

• MK: The main thing to be aware of is that it involved changing a number of the formal expansions of other functions. For example, fn:replicate is no longer easily defined in terms of fn:fold-left.

Proposal: Accept this PR.

Accepted.

See PR #1883

MK introduces the PR and reviews the examples.

• MK: One key difference is that the this function is going to be most useful when it’s going to be reused.
• MK: I was most motivated by the use of the compose in a callback function.
• MK: It’s simpler than fn:chain, it returns a function rather than applying the function and it doesn’t handle the complexity of handling functions with arities other than one.
• DN: I fully approve of fn:compose, but I think there’s a questionable thing as well.
  • … There’s no way to compare fn:compose to fn:chain. The fn:chain function provides more functionality than fn:compose in every case.
  • … There is a difference of quality here.
  • … One of the main differences, one of the things that fn:chain provides, is the ability to have multiple arguments.
  • … In fn:chain, there are 25 examples and in 8 of them, there’s a function with arity greater than one.
  • … One might say that such functionality is rarely used. But that’s like saying an airplane is rarely used. That’s true, but it’s very useful.
• JLO: I am not a fan of fn:chain and I’d be happy with just fn:compose.

There’s a typo in the last example: “let”.

• JLO: Trying to combine functions with variable arity using fn:chain has a lot of edge cases. I like this better.
• MK: My main thinking on this was that if you know statically what functions you want to call, it’s very easy to compose them using the arrow operator. The case for the compose function is when you have dynamic functions to compose. With fn:chain as it’s currently defined, you have to know what the arities are so it’s hard to find examples of creating a completely flexible function chain. I found that logic complex; it’s going to sometimes work, but I found it frustrating.
  • … I also trying to exercise some discipline, removing something to prevent duplication.
• RD: Would it be possible to restrict fn:compose to functions of the same arity.

Discussion to continue.