@qt4cg statuses

123 ! string-length() is interpreted as 123 ! string-length(string(.)), while string-length(123) raises an error. This is confusing.

Maybe we should allow fn:string-length#1 to accept input of type xs:anyAtomicType; this would also make it symmetric to fn:string-join.

I don't think we've got this right. The combination of decoding a slice of a string starting at a given offset, and then detecting a BOM depending on the offset (and presumably adjusting the offset based on the presence of a BOM) is just too confusing.

I propose:

• The decode-string function accepts an encoding argument with a simple unconditional default of UTF-8.
• If the user wants to ignore a BOM they should adjust the start offset accordingly.
• A new function infer-encoding($input as binary) that returns a record containing (a) the inferred encoding, and (b) the start offset of "real" data after any BOM.

Fixes issues that are tick-marked in issue #2195

The rules for vendor extensions in XSLT are unnecessarily strict. For example:

The presence of an extension attribute must not cause the [principal result] or any [secondary result] of the transformation to be different from the results that a conformant XSLT 4.0 processor might produce. They must not cause the processor to fail to raise an error that a conformant processor is required to raise.

This greatly reduces the usefulness of vendor extensions (for example, some of Saxon's serialization extensions, such as @saxon:canonical=yes, are non-conformant) without actually offering any useful increase in interoperability.

I think that in practice implementors have not felt bound by such rules. In practice there is wriggle room anyway: for example if you provide a switch to disable all extensions, then you can say that with that switch set, your processor is a conformant processor.

We should align the extensibility rules across all the specs.

Copied from https://github.com/qt4cg/qtspecs/issues/1953#issuecomment-2830012997 and updated:

The value of the current record constructor is pretty limited when it comes to updating existing records – and it is fairly ugly to use repeated map:put calls. With extensible records, it is already possible to pass an existing record to the constructor as last argument…

declare namespace geo = 'geo';
declare record geo:coord(x, y, *);

let $coord := geo:coord(0, 0, { 'z': 7 })
return geo:coord(3, 5, $coord)

This gives us:

{ "x": 3, "y": 5, "z": 7 }

However, the use cases for this variant are limited, and all mandatory arguments need to be supplied, even if they don’t change.

I propose to change the constructor, and define the first argument as a container for an existing record. This way, the same result as above could be achieved with the following code:

let $coord := geo:coord({ 'z': 7 }, 3, 0)
return geo:coord($coord, y := 5)

If all mandatory record arguments are supplied via keywords in the constructor call, the first argument can also be omitted:

geo:coord(x := 3, y := 5)

The generated constructor function could be something like:

declare function geo:coord(
  $record as map(*)? := {},
  $x := (),
  $y := ()
) as geo:coord {
  map:merge((
    { 'x': $x otherwise $record?x },
    { 'y': $y otherwise $record?y },
    $record
  ), { 'duplicates': 'use-first' })
};

Challenges might be intricacies like the explicit assignment of empty sequences, but I think that the advantages would prevail. The syntax could also be used more easily for chaining:

geo:coord({ 'z': 7 }, 0, 0)
=> geo:coord(x := 3)
=> geo:coord(y := 5)

Fix #407

The PR clarifies with examples that

(a) a dynamic function call can include several functions: (upper-case#1, lower-case#1)("London") (b) an arrow expression can include several functions: "London" => (upper-case#1, lower-case#1) (c) a method call can apply to multiple maps: for $size in 1 to 3 return $rectangle =?> resize($size) =?> area()

None of this actually represents a change to the spec, just a clarification that it is already allowed.

I'm not in favour of the change proposed in issue #2219 allowing the RHS of =?> to select zero or more functions. If we wanted to allow that, we probably wouldn't want to restrict the RHS to be an NCName. Using an NCName gives better potential for optimization and for static error detection, and I think it makes sense to require it (as now) to select a single function from each input map.

Fix #2219

Fix #2253

Fix #2260

Fix #2267

Fix #2268

The equivalent expression for fn:for-each-pair() is given as:

for $pos in 1 to min(count($input1), count($input2))
return $action($input1[$pos], $input2[$pos], $pos)

but fn:min() takes a sequence as first argument and collation as optional second. Thus the equivalent should be

for $pos in 1 to min((count($input1), count($input2)))
return $action($input1[$pos], $input2[$pos], $pos)