@qt4cg statuses

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.

This should resolve some warnings and support modern versions of Java. This PR also switches from Groovy to Kotlin for the build scripts. A few plugins have been added and there’s been a small amount of reorganization to simplify the tasks. Using plugins required "unpacking" some multi-step tasks into several top level tasks. These new tasks have names that begin with "_" in an attempt to indicate that they’re "internal".

(I have no idea if this will build successfully as a PR. The PR certainly isn't going to test the new build scripts.)

I've tried to carefully check that the build produces the same output. It appears to:

• The index.html file in grammar-explorer is different because I added a meta charset element to it.
• The top-level index file is different because I added a link to the grammar explorer.
• The xslt-streaming.xml file present in the old build was an accident, I think.

(If you try to reproduce this comparison, set the Saxon version in gradle.properties to 12.9. I've updated to 12.10, but that changes all of the HTML files by a few bytes in the comment at the end.)

@Arithmeticus if you pull this branch you should be able to build with Java 25.

@michaelhkay and/or @ChristianGruen I'd appreciate it if you could smoke test this before we merge it and confirm that it "works for you".

#Fix 2302

Fix #2302

Adds notes to substring-(before|after)[-last] explaining the effect of the "minimal match" rule when the collation includes ignorable characters.

Fix #2973

The URI functions currently break the UNC round trip:

let $options := { 'unc-path': true() }
return 'file:////uncname/path' => parse-uri($options) => build-uri($options)

…returns file://////uncname/path.

A plain :// already gives the right URI, so maybe it suffices to drop the ://// rule?

With the just added fn:update function it is tedious to rename nodes: existing entries need to rebuilt. We could simplify with an fn:rename function, which could also be used standalone:

fn:rename(
  $node  as gnode(),
  $name  as xs:anyAtomicType
) as gnode()

Examples:

rename(<item id="1">A</item>, 'entry')
rename(<a b="1"/>/@b, QName('urn:x', 'x:b'))

(: XNodes today :)
update($doc, fn { //item }, fn($item) { element entry { $item/@*, $item/node() } })

(: XNodes with rename :)
update($doc, fn { //item }, rename(?, 'entry'))
update($doc, fn { //@class }, rename(?, 'role'))

(: JNodes today :)
update($json, fn { //customer-id }, fn { { 'customerId': jvalue() } })

(: JNodes with rename :)
update($json, fn { //customer-id }, rename(?, 'customerId'))

Moving the EXPath specs broke generating tests. It's not at all clear to me how or why but this seems to fix it.

Some more minor changes (some of them made explicit):

• file:resolve-path: normalizes all paths (native separators, ./.. removed) and keeps a trailing separator. $base counts as a directory only if it ends with a separator.
• file:write-binary: $offset now defaults to (). Without it, the file is replaced; with an explicit 0, bytes are overwritten in place.
• file:base-dir: returns the base URI itself if it points to a directory.
• file:copy/file:move: missing parent directories are created, and copying or moving into the source's own directory does nothing.
• Renamed parameters: file:write-text-lines($values) is now $lines; file:children/file:descendants $path is now $dir.

…and editorial trivia.

Fix #2473

I'm pretty sure they still build correctly. It's possible some links will need fixing on qt4cg.org; I'll look at those in a few minutes. I'm also working on a more substantial update to the Gradle build scripts to account for modern versions of Java. That should be coming today as well, so I'm going to wait until after that to look at tidying qt4cg.org.

(This is a "build-only" PR so I'm just going to merge it optimistically.)

Fix #2982

As I commented during the review of fn:update, I feel the rules for fn:update handling of the $replacement argument are rather complex and not very intuitive. I propose to experiment with an alternative in which $replacement is always a function that returns a record consisting of an action such as "delete", "replace", "rename" etc, and a value whose interpretation depends on the action.