[Bug 29917] New: [FO31] xml-to-json - processing a subtree

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29917

            Bug ID: 29917
           Summary: [FO31] xml-to-json - processing a subtree
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.1
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 6 October 2016 13:43:02 UTC