[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=31979#action_31979 ] 

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

Googling it, I see a lot of complaints about JSON libraries omitting 'null' etc. It certainly goes both ways. The specific example you quote appears to be an issue between json-lib and Jackson, not between serializers and JSON. At any rate, it seems to me the responsibility of the application author to feed his/her serializer objects that result in the desired JSON. In your case, that would be either a null object or a String with null embedded. None of this is a JSON issue.

Twitter, for one, uses null in its JSON, which is a strong indicator to me that there is nothing wrong with this approach. Example:

{ 
    "created_at": "Mon Dec 17 19:44:43 +0000 2012", 
    "id": 280760456388411400, 
    "id_str": "280760456388411394", 
    "text": "Our xmas tree is quite a mixer. It's got a mirror ball, martini glass, Ravens gear, Martis Gras mask, 2 of the kings & a bunch of penguins.", 
    "source": "web", 
    "truncated": false, 
    "in_reply_to_status_id": null, 
    "in_reply_to_status_id_str": null, 
    "in_reply_to_user_id": null, 
    "in_reply_to_user_id_str": null, 
    "in_reply_to_screen_name": null, 
    "user": { 
        "id": 14640100, 
        "id_str": "14640100", 
    ...
    }
}


> You are attempting to make JSON serializations self-describe the structure of the resource that they are serializations of

I wouldn't use the term "self-describe". I want a serialization to be the exact representation of the structure, not a minimized version of it.

Regarding my "date.timezone" example: this is a well-known PHP configuration variable. Virtually every PHP developer knows that it needs to be set as well as what values it accepts. The point I was trying to make with this example was that the user needs to see that it is empty. It is important information.


> 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