@qt4cg statuses

Fix #2933

Replacement for PR #2918, rebased to avoid merge conflicts

With #2918, a source that is requested by fn:collection won’t be processed recursively. I think we should change the default of recursive to be implementation defined.

This resolves the merge conflicts between my reworking of the build scripts for Gradle 9.x and @ChristianGruen 's updates for serialization parameters.

Close #2985 Close #2984

Per the description in #2985, #2981 will have to be rebased. It’s not immediately clear to me how straightforward that will be

Fix #3011

Changes the handling of NaN in XQuery order by clauses to be sensitive to "empty greatest", as it was in 3.1.

A number of new tests have been committed in test set EmptyOrderDecl demonstrating that XQuery 4.0 produces different sort results from 3.1 in the case of a sequence that includes NaN values. These changes are attributed to a change in the spec consequent on PR #2256.

When I wrote that PR, and when we reviewed it, I don't think we were conscious that we were introducing an incompatible change, and the change is not highlighted in the list of incompatibilities. I'm therefore raising the issue for discussion: do we actually want to make this incompatible change?

To be clear: Sorting the values (), NaN, 1, 4, 7

• In 3.1 with empty least, the result is (), NaN, 1, 4, 7
• In 3.1 with empty greatest, the result is 1, 4, 7, NaN, ()
• In 4.0 with empty least, the result is (), NaN, 1, 4, 7
• In 4.0 with empty greatest, the result is NaN, 1, 4, 7, ()

Now, I think the 3.1 rules are pretty bizarre (the rationale is probably that SQL has a similar capability if you equate () with SQL's null). I can't imagine that many people use "empty greatest", but if they do, I see no particular reason to impose an incompatible change on them. The bar for an incompatible change should be very high (the fact that we think the new rules are better is not a strong enough reason), and I don't think the justification here is strong enough.