@qt4cg statuses

Transferred from https://github.com/qt4cg/qt4tests/issues/505

Type inferencing with type xs:error is a mess.

In principle, xs:error is a subtype of every other type (because its value space, being empty, is a subset of every other value space), so the substitutability rule should mean that an expression with type xs:error is substitutable for any other type, which would mean that a call on fn:error() never results in a type error.

But we also say that a type error can be raised statically if the intersection of the supplied type and the required type is empty, and if the supplied type is xs:error then its intersection with any other type is always empty (there are no values that are instances of both types), so a statically inferred type of xs:error is therefore a type error wherever it occurs, which can't make sense because it would make every call on fn:error() statically reportable.

It would make sense for the $err:map variable available in a try/catch to be a labeled record rather than a simple map.

Fix #3047

Test case PathExpr-J-020 does

let $x := (validate type xs:integer {<x>1</x>}, validate type xs:integer {<y>2</y>}) return
        (['a', 'b', 'c'], ['b', 'c', 'd'], ['e', 'f', 'b'])[./$x = 'b']

and expects the result (['a', 'b', 'c'], ['b', 'c', 'd'])

I think this is a reasonable expectation, but it depends on something that isn't in the spec. The big question is: in the path expression ./$x, given that . is a JNode, and that the selector interpretation applies to $x, is $x atomised? In this case $x holds an sequence of two XNodes which, when atomized, return (1, 2).

The spec doesn't say that $x is atomised, and I think that it should.

Note that atomisation affects the outcome not only when $x is an XNode, but also when it is (say) an array or a JNode.

If $x isn't atomized, then §4.6.3 says "the result is those children of N whose ·jkey· property matches its value." where matches is nowhere defined.

Closes #2999

Tests: https://github.com/qt4cg/qt4tests/pull/504

I wanted to write a proposal for #2846 (to tweak the serialization of file:write and file:append), but I noticed I need to start with fn:serialize, and I failed to understand how the rules are meant to work.

I believe it is easy to misinterpret following sentence, which has already been added in 3.1:

If the second argument is omitted, or is supplied in the form of an output:serialization-parameters element, then the values of any serialization parameters that are not explicitly specified is ·implementation-defined·, and may depend on the context.

I am tempted to carefully read it as…

• if I omit the options argument, the values of all parameters are implementation-defined (no matter what the spec names as default);
• if I supply it, maybe by just using an empty options argument {}, all default values will apply;
• all values of the parameters that I omit as children of output:serialization-parameters element will again be implementation-defined; and
• only those default option values that are listed in the spec will ever apply when I specify an options argument that does not override the defaults.

It also includes a minor typo (“is” → “are”).

I am pretty sure it wants to say something different, but I lack the historical knowledge:

1. what exactly was meant to be implementation-defined in 3.1 (possibly earlier), and
2. which implementation liberties must/should we preserve in 4.0?

Closes #3043

See https://github.com/qt4cg/qtspecs/issues/2576#issuecomment-6627158408 and older issues:

A coerce as expression will be helpful to make coercions explicit. For example, it will allows us to write…

{ 'a': 1 } coerce as record(a)

…instead of…

let $a as record(a) := { 'a': 1 }
return $a

Similar as fn:distinct-ordered-nodes, it will only be fully understood and used by expert users, but it won’t harm anyone else (and it’s much more useful today than treat as).

Attempts to resolve #2848 by fairly small amendments to the essay on determinism. Note that the text has been moved into a new section (and partitioned into subsections), so the change is much smaller than the diff might imply. Hopefully these changes are enough to resolve the issue.

Fix #2848

Fix #2884

Fix #2996

Fix #3021 -- change keyword %static to %fixed

Fix #3038 -- move semantic constraints into the grammar

I combined these proposals because there would otherwise be conflicts