This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Test case xml-to-json-070 applies.
The WG agreed to make this change.
The change has been applied to both the F+O 3.1 and the XSLT 3.0 specifications. Test case xml-to-json-070 has been updated with the new expected results.