ResourceReferenceList serialization? about acme-onem2m-cse HOT 8 CLOSED

Since the implementation passes the relevant oneM2M test cases and interoperates with other implementations I would say the implementation is correct. The XSD is also correct, because the <xs:complexType name="childResourceRef"> is just extending xs:anyURI by using the <xs:simpleContent> element. It does not define a new type per se.

from acme-onem2m-cse.

yeah, i think the issue here is the ambiguous nature of applying an xsd schema to json serialization. specifically that an xsd can specify a sequence of named elements:

  <xs:complexType name="listOfChildResourceRef">    
    <xs:sequence>
      <xs:element name="childResource" type="m2m:childResourceRef" minOccurs="0" maxOccurs="unbounded" />      
    </xs:sequence> 	       
  </xs:complexType> 

which in XML would match

<foos>
  <childResource ... />
  <childResource ... />
  <childResource ... />
</foos>

but in json, you can't have this. array elements don't have names. so, if that name (childResource) is to be honored in the json serialization, should it be

"foos": [
  { "childResource": ... },
  { "childResource": ... },
  { "childResource": ... },
]

or

"foos": {
  "childResource": [
    ...
  ]
}

? neither of which match the implementation. (btw: the latter version is how my codegen interprets this, hence my original question)

if, on the other hand, the name childResource should be discarded in the json serialization as the implementation suggests, what happens to the names in the following declaration:

  <xs:complexType name="aggregatedResponse">    
    <xs:sequence>
      <xs:element name="resourceID" type="xs:anyURI" minOccurs="0"/>      
      <xs:element ref="m2m:responsePrimitive" minOccurs="0" maxOccurs="unbounded"/>      
    </xs:sequence> 	       
  </xs:complexType>

from acme-onem2m-cse.

I agree, XML/XSD is so much richer, more expressive, and less ambiguous than JSON.

Perhaps you should have a look at TS-0004, clause 8.4. There, the JSON serialisation rules are explained, together with examples.

For your last example (out of my head and I might be wrong), this would be:

"aggregatedResponse" : [
    { "resourceID" : "aURI", "responsePrimitive" : ... },
    { "resourceID" : "anotherURI", "responsePrimitive" : ... }
]

from acme-onem2m-cse.

ah, so how come aggregatedResponse is

"aggregatedResponse" : [
    { "resourceID" : "aURI", "responsePrimitive" : ... },
    { "resourceID" : "anotherURI", "responsePrimitive" : ... }
]

where the sequence's elements (resourceID and the referenced m2m:responsePrimitive) are serialized as named properties of the array element.

and listOfChildResourceRef is

{
    "listOfChildResourceRef": [
        {
           //m2m:childResourceRef properties
        }
   ]
}

where the <xs:element name="childResource" name is discarded and the m2m:childResourceRef are included directly as elemnts of the array?

surely the level of indirection here is inconsistent.

btw: is there an open, active place online for discussing spec issues like this? i tried the mailing list a while ago but it seems dead.

from acme-onem2m-cse.

I guess this has something to do with Rule 13) of the clause I mentioned above:

13. If an element has an XSD data type that is a complex type with XML attributes, then it is serialized in JSON as an object. The XML attributes appear as members of that object (using their short names) as do the XML elements.

oneM2M is currently revamping the web presence. Technical discussions in public can be started here: https://github.com/oneM2M/Issues-Questions, but this is currently in the set-up stage. It would be great, though, if you can start a discussion over there to stimulate this forum (though people might have already started their xmas vacations).

from acme-onem2m-cse.

UPDATE:

OK, so I just discussed the issue you raised regarding the inconsistency with a oneM2M colleague, and we discovered a couple of things that need to be fixed. You are right in pointing out that the XSD doesn't match the spec. We also came to the conclusion that TS-0004, table 7.5.3-2, need to reflect that the result set could be empty (if no match was found during the discovery). Currently, the cardinality of "listOfChildResourceRef" is 1..N, and therefore cannot be empty. But in TS-004, 7.3.3.14 Discovery related procedures, the text after step 6, indicates that an empty list shall be returned when the result set is empty.

Actually, the result should be similar to the encoding of the "acr" of ACP resources.

We will raise this issue within the working group after Christmas . Thank you very much for reporting and discussing this!

from acme-onem2m-cse.

actually my question wasn't about the cardinality of listOfChildResourceRef. it was more about the difference in the way that the child properties of aggregatedResource and listOfChildResourceRef are interpreted: I don't understand what it is in the schema that specifies that an aggregatedResource is an object whereas a listOfChildResourceRef is an array.

also, i posted a question here: oneM2M/Issues-Questions#1

from acme-onem2m-cse.

Sorry, if I was not clear enough. We discussed your question and agree that there is a problem here. We looked at the spec in TS-0004 and find that it is ambiguous already on the textual level. This needs to be fixed first, only then can we agree on fixing the XSD.

We prepared an input contribution to discuss the options in the working group. But until then I cannot give you a definite answer what would be the correct encoding, because both the text and the schema don't even match right now.

Regarding your issue one the oneM2M issue tracker: thanks for that! I think you are right. This error must have been creeped in at some time. But as I said: all the people monitoring this tracker are on vacation over the Christmas season.

from acme-onem2m-cse.