@qt4cg statuses

1. The term “segments” is somewhat uncommon in the regex terminology. Maybe fn:match-results?
2. A common use seems to be to get the strings captured by the groups of a match:

let $groups := matching-segments($line, '(\S+) (\S+)( \S+)?')?groups
let $a := $groups?1?value, $b := $groups?2?value, $c := $groups?3?value

Maybe we should add a field values (of type array(xs:string?))? It could also be used for destructuring:

let $[$a, $b, c] := matching-segments($line, '(\S+) (\S+)( \S+)?')?values

Closes #2965

1. Contradiction, about newlines at the end of a string. With the m flag, one section says ^ and $ work around every newline. Another section (a later correction) says a newline at the very end of the string is an exception. The test suite follows the correction, so the older section should be updated to match. It should also say clearly what $ does there.

2. Typo in the x flag. The list of removed whitespace characters names the carriage return twice and forgets the ordinary space. The example right below it only works if spaces are removed.

3. A rule that common regex engines don’t support. \1 refers back to the text that group 1 matched. If group 1 didn’t match anything at all, the spec says \1 should match the empty string. Java etc. make the whole match fail in that case, and imitating the spec’s rule takes a lot of extra machinery. I’d suggest dropping the rule, or letting each implementation decide.

4. Optional: upper/lower case in \1. With the i flag, the spec’s definition says Turkish İ and i are different letters. Java treats them as the same when comparing \1. After all, this only affects a handful of special letters, so maybe the spec could simply leave it to implementations…

Fix #2937

Adds a note explaining that " John " cannot be relabelled as xs:ID

Fix #2960

I decided to not go without strict-quoting, but to allow quotes within the input string, which is the most common case, and much less controversial. FOCV0001 covers only broken quoted fields now.

Closes #2961

1. I suggest dropping fn:csv-to-arrays: fn:parse-csv($s)?rows returns exactly the same result, and there is no implementation for the first function that is really cheaper.
2. Input with embedded quotes is not that rare (example: Monitor, 24" wide). In some cases, this input can still be read by supplying an exotic quote-character, but I think a strict-quoting option would be better. We could also be less strict, but by experience this results in ambiguous cases (for example, is "abc" def,x supposed to be right or wrong?)

The coercion rules say:

If R is derived from some primitive atomic type P, then J is relabeled as an instance of R if it satisfies all the following conditions:

• J is an instance of P.
• J is not an instance of R.
• The [datum] of J is within the value space of R.

Now consider (new test case FunctionCall-433)

         declare function local:f($x as xs:NCName) { $x };
         local:f(" RED ")

I think that under a strict reading of the rules, this should fail: the string " RED " is valid as an instance of xs:NCName but it is not in its value space.

We should either change the rules, or at least add a note.

Fix #2942

Fix #2957

I propose:

(a) to make automatic creation of constructor functions available for nominative record types only (b) to make creation of a constructor function for a given record type optional (c) to use the default values defined for fields for casts and coercions as well as for the constructor function (d) to allow selected fields in a nominative record type to be declared as static, in which case the default value becomes a fixed value : the field cannot be set using the constructor function, and cannot be modified by casting, coercion, or by the "but with" operator.

Accepted (see https://qt4cg.org/meeting/minutes/2026/09-29.html). Issue: #2919

Accepted (see https://qt4cg.org/meeting/minutes/2026/09-29.html). Issue: #2919

Accepted (see https://qt4cg.org/meeting/minutes/2026/09-29.html). Issue: #2919

Accepted (see https://qt4cg.org/meeting/minutes/2026/09-29.html). Issue: #2919

Accepted (see https://qt4cg.org/meeting/minutes/2026/09-29.html). Issue: #2919

Accepted (see https://qt4cg.org/meeting/minutes/2026/09-29.html). Issue: #2919

Accepted (see https://qt4cg.org/meeting/minutes/2026/09-29.html). Issue: #2919