@qt4cg statuses

The enclosed-expression selector axis::{ E } coerces E to (xs:QName | xs:string)* for XNodes, but to xs:anyAtomicType* for JNodes, where any non-matching key simply selects nothing. This asymmetry means the same selector $x/child::{ $keys } raises a type error when $x is an element, yet silently matches nothing when $x is a map or array.

I think we should handle the XNode case leniently as well: atomic items in the selector value that are not xs:QName or xs:string values are simply ignored (they match nothing), as was already stated in a note for the former get() selector. This keeps the two node kinds parallel and avoids surprising, kind-dependent failures when the key sequence is computed generically. Raising no error would also live up to the XPath 1.0 tradition.

If we want to keep the current error handling, we should also reject other cases in which the resulting selector makes no sense:

$node/1       (: ↯ :) 
$node/"x y"   (: ✓ currently accepted, even though the string is an invalid local name :) 
$array/x      (: ✓ currently accepted, even though arrays cannot have string keys :) 

…probably editorial, but I decided to give it a separate issue:

The current spec says:

It is permitted, though not generally useful, for the enclosed expression to be focus-dependent, in which case its value will vary from one selected node to another. For example, child::{@name} selects those child elements whose local-name is equal to the value of their @name attribute.

This is not reflected by the equivalent code yet:

let $A as (xs:QName | xs:string)* := E 
return AXIS::*[some $a in $A, $n in (node-name(.), local-name(.)) 
               satisfies atomic-equal($a, $n)]

Fix #2677

In many scenarios, comparisons can be sped up a lot by replacing sequences with maps. For example, the following code might take O(n²) if a processor should fail to use a hash join at runtime:

let $known := $old
return $new[. = $known]

With the current 4.0 map constructor syntax { EXPR }, the example from above can be rewritten as follows:

let $known := { $old ! map:entry(., true()) }
return $new[map:contains($known, .)]

We could improve the status quo by automatically creating map entries with data(ITEM) as key and true() as value for each item which is no JNode or map. This would allow us to write:

let $known := { $old }
return $new[$known(.)]

I believe the compact syntax could be helpful in many scenarios where maps are used as sets. Of course one could write map:build($old) if all EBV of the items are known to be true, but replacing round by curly brackets seems so much nicer.

In #1949, I suggested to strictly follow the type rules supplied by users. Specifically, I believe a value that is specified to be a number should be output as such, or an error should be raised.

If we decide to stick with a more lax approach (as proposed by the PR for this issue), maybe we could introduce a mode option instead:

(: would raise an error, as 'haha' is no boolean :)
element-to-map(
  <a>haha</a>,
  { 'plan': { 'a': { 'layout': 'simple', 'type': 'boolean' } }, 'strict': true() }
)

I would prefer strict to be the default. Otherwise, when you design and apply a plan, you will never know which rules are observed and which are ignored.

Modified parse-csv() and csv-to-arrays() to add support for comments.

Fix #2689

Fix #2695

There are three parts to the challenge of making template rules work effectively for transforming JSON-derived trees.

The first part is designing match patterns that work effectively. We have largely achieved this with PR2678, though I think there is still work to do on matching records.

This second part is concerned with the apply-templates instruction.

The final part, which I think can be tackled independently, is to define the effect of the built-in default template rules, especially those for mode="shallow-copy".

For apply-templates with a select expression, I propose no change, if only because the semantics are already defined in XSLT 3.0.

In the absence of a select expression, the current rule is that it's an error if the context item is not a node (XNode). I think we can do better than that.

If the context item is an atomic item, we should apply templates to that atomic item.

If the context item is a JNode, we should apply templates to the children of the JNode; and if the context item is a map or array, we should wrap the map or array in a JNode and apply templates to its children.

There's then a question, if you're processing a map or an array, whether the results of apply-templates should be used to construct a new map or array, or whether (as now) they should be left as a sequence. I'm inclined to say that if you want an array or map, you construct it yourself, so you write

<xsl:array>
  <xsl:apply-templates/>
</xsl:array>

<xsl:map>
  <xsl:apply-templates/>
</xsl:map>

It becomes the responsibility of the author of the template rules to return values that are suitable for use in constructing an array or a map.

The recent addition of the TraceClause in #2676 caused LALR(2) parser generation to fail (see GitHub action log). This is fixed here by adding trace to the list of reserved keywords for constraint unreserved-name.

With the introduction of custom patterns for matching maps, arrays, and JNodes, there is considerable overlap between these new patterns and existing type patterns; in addition, the syntactic similarities may lead to confusion. The differences between the type pattern ~array(xs:integer) and the array pattern array(~xs:integer) are subtle...

One option would be to offer type patterns only for atomic values, or perhaps for named record types.

Another possibility would be to repurpose the ~ as a short form of the instance of operator, and to use type testing exclusively within predicates. So the type pattern ~map(xs:integer, xs:string) would be replaced by the predicate pattern .[~map(xs:integer, xs:string)].

These questions came up during the XQuery 4 tutorial held on XML Prague 2026

Question 1: Can destructured variables have a sequence type?

Is it possible to declare the (sequence)type when destructuring sequences into items.

let $($a as xs:positiveInteger+, $b as numeric()*) := (1, 2.9, -3, xs:double("Inf"))

If this is possible do we have to raise errors must be raised for

let $($a as xs:string, $b as numeric()) := (1, 2.9, -3, xs:double("Inf"))

Is the below construct possible?

let $($a, $b) as numeric()* := (1, 2.9, -3, xs:double("Inf"))

Question 2: Destructuring arrays and excess members

Given a code like let $[$a, $b] := [1, 2, 3] The current implementation in BaseX will discard any excess members in the array. There is no way to destructure the rest of the array members. This is different from the sequence destructuring.

Should this

• raise an error - as it does in python - as excess array members would be discarded?
• should $b instead select (2, 3) so that the last destructuring variable selects the tail end of all members not yet selected?
  • let $[$all] := [1, 2, 3] would be equivalent to let $all := [1, 2, 3]?*

Question 3: Destructuring in function parameters

It is quite common in JavaScript to destructure object arguments into only those properties that are actually needed. Here is a rather theoretical example how that could look like in XQuery

declare function nextX(${$x}) { $x + 1 };

nextX({"x": 1, "y": 1})

Question 4: Renaming map entries in map destructuring

This is a Adding two complex numbers could be achieved with a renaming destructuring operation.

declare record complex:number(r as xs:double, i as xs:double);
declare function complex:add (${$x:r, $y:i}, ${$u:r, $v:i}) {
    complex:number($x + $y, $u + $v)
};

Renaming could also allow desctructuring of maps with keys other than NCNames.

Fix #2683. We discussed the issue today and this PR reflects the decision.