This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29917 - [FO31] xml-to-json - processing a subtree
Summary: [FO31] xml-to-json - processing a subtree
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-06 13:42 UTC by Michael Kay
Modified: 2016-12-16 19:55 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2016-10-06 13:42:51 UTC
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.
Comment 1 Michael Kay 2016-10-06 13:51:45 UTC
Test case xml-to-json-070 applies.
Comment 2 Michael Kay 2016-10-18 15:23:23 UTC
The WG agreed to make this change.
Comment 3 Michael Kay 2016-10-18 23:32:45 UTC
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.