The XQuery 3.1 specification states that when an array appears within the content of an element constructor, it is atomized. For example

<a>{[<b/>, <c/>, <d/>]}</a>

produces the output

<a/>

This seems to conflict with the decision we made for serialization, where we said that if nodes appear within an array during JSON serialization, the nodes are expanded using XML serialization. It also seems counter-intuitive since element constructors do not normally atomize any nodes appearing within their content; it seems odd to treat enclosed nodes differently just because they appear within an array.

I think it would cause fewer surprises if an array appearing in such a context were recursively flattened (that is, replacing $A by $A?*) rather than being atomized.

Incidentally, there is also a problem with the way the rules are given in section 3.9.1.3: rule 1.e.ii should appear before 1.e.i, because otherwise, arrays are rejected by virtue of the fact that they are functions.

I agree with both statements in comment 1.

If we're going to accept this then we need to define what we mean by "recursively flattening". Here's a candidate definition.

To (recursively) flatten a sequence $S, apply the function

function flatten($S as item()*) as item()* {
for $s in $S return
  if $s instance of array(*)
  then flatten($s?*)
  else $s
}


Rules 1e(i) and 1e(ii) of 3.9.1.3 then become

(i) the sequence returned by the enclosed expression is flattened.
(ii) if the sequence resulting from step (i) contains a function, a type error is raised [err:XQTY0105].

and rules (iii) and (iv) should be phrased to make it clear that they refer to the sequence after applying (i) and (ii)

Let's add the function from comment #3 to F&O - fn:flatten() - and refer to it from the XQuery / XPath specifications.

The proposal was today accepted, including the addition of the flatten() function (which has been put in the array: namespace)

Confirmed fixed in the current draft.