Calling json-to-xml() might produce an output document $doc such as this:

<j:map>
  <j:array key="givenName">
      <j:string>Michael</j:string>
      <j:string>Howard</j:string>
  </j:array>
  <j:string key="lastName">Kay</j:string>
</j:map>

Now it seems reasonable to call xml-to-json($doc//*[@key="givenName"]) and expect the output

["Michael","Howard"]

However, this fails, because the node supplied as input to xml-to-json() cannot have a @key attribute.

The problem is that in the schema, the global element declarations don't allow a "key" attribute (the type definition for map uses local element declarations for array, string, etc, which do allow this attribute). If the input is typed, the relevant j:array element will be annotated with the type j:arrayWithinMapType, whereas we require j:arrayType.

I think it would be a good idea to relax the rules so that this case does not fail.

We currently say:

The node supplied as $input must be one of the following:

1. An element node whose name matches the name of a global element declaration in the schema given in C.2 Schema for the result of fn:json-to-xml ("the schema") and that is valid as defined below:
   a...
   b...
   c...

2. A document node having exactly one element child and no text node children, where the element child satisfies one of the two [should be THREE] conditions above.

We could add:

3. An element node having a key attribute which becomes valid under rules 1(b) or 1(c) above after stripping the key attribute.

We could also expand rule 1(a) to enumerate all the type annotations that are considered valid, including the types such as j:arrayWithinMapType as well as j:arrayType.