[OASIS Issue Tracker] Commented: (CAMP-32) CAMP needs to say something about the serialization of null attribute values and empty arrays

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31990#action_31990 ] 

Tobias Kunze  commented on CAMP-32:
-----------------------------------

I just don't see the interop issues and whatever those are, they seem to be entirely within the libraries used as well as configurable and standardizing on a minimization scheme doesn't remove them (libraries are still free to interpret a "null" string as NULL or a String object with a null string inside, for instance). As far as JSON is concerned, "{}" and "{'a': null}" are two different objects, so mandating such behavior is causing interop issues, not the other way around.

Also, what is so special about "null" or empty arrays? Why not minimize empty hashes as well? Or empty strings? Or hashes with only one parameter? It just doesn't make any sense. If I have

    struct point {
        long x = NULL;
        long y = NULL;
    };

its correct JSON serialization is

    {"x": null, "y": null}

and not "{}". The fact that this is a structure with two properties, "x" and "y" is as critical as the fact that they don't have any values assigned. After all, it represents a point in the cartesian plane, not in polar coordinates or a Twitter message that just happens to also minimize to "{}".

As I said before, I get the cultural issue and the bandwidth issue, but would discount the latter as irrelevant and the culture issue as less important and not universal (see the Twitter example). I do not see the interoperability issue. On the contrary, in our case where client and platform have no shared knowledge about the structure of objects serialized as JSON, it is paramount that those objects are serialized in a lossless and thus reversible manner.

As a result, I suggest we close the issue or even add language that serialization MUST not minimize structures.

> CAMP needs to say something about the serialization of null attribute values and empty arrays
> ---------------------------------------------------------------------------------------------
>
>                 Key: CAMP-32
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-32
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>
> The following JSON:
> {
>   "uri" : "http://slc03lgx.us.oracle.com/campSrv/Assembly/9";,
>   "name" : "/examples",
>   "description" : null,
>   "created" : "2012-11-14T08:33-0800",
>   "tags": []
>   ...
> }
> Is semantically equivalent to:
> {
>   "uri" : "http://slc03lgx.us.oracle.com/campSrv/Assembly/9";,
>   "name" : "/examples",
>   "created" : "2012-11-14T08:33-0800",
>   ...
> }
> However, different languages and mappings treat these representations in different ways. For the sake of interoperability we should consider avoiding these differences by adding requirements to CAMP regarding the serialization of empty arrays and non-existent values.
> We could:
> 1.) say that clients and servers MUST NOT send either 'null' attributes or empty arrays
> 2.) say that clients and servers SHOULD NOT send either 'null' attributes or empty arrays
> 3.) say that clients and servers MUST NOT send 'null' attributes and SHOULD NOT send empty arrays
> 4.) say that clients and servers SHOULD NOT send 'null' attributes and MUST NOT send empty arrays
> We could also blow out the above choices with the additional factor of allowing clients and servers to have different behavior. For example "Clients MUST NOT send 'null' attributes but servers SHOULD accept them". I've had experience with this sort of thing (in the WS-I profiles) and it rapidly gets weird. IMO it is naturally outside the scope of any specification to define how one party in an interaction should behave in the face of non-compliant behavior on the part of another party. If a CAMP service implementation wanted to be "generous in what it receives", it should be free to do that, but I don't think we can mandate that behavior.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira