[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=31977#action_31977 ] 

Gilbert Pilz commented on CAMP-32:
----------------------------------

To get a sense of the interoperability issues re-google "json serialization null" as you, yourself, recommended a couple of comments back. Here's a nice little snippet:

"We have just migrated from json-lib to Jackson; but the problem we are facing is that json-lib converts null Strings to  empty strings, whereas Jackson converts null string to null value. This has created lot of compatibility issues with the existing code."

It's hard not to see your argument as an attempt to use JSON as its own schema language when you say that it is important for every serialization to be "explicit about the structure of a resource". You are attempting to make JSON serializations self-describe the structure of the resource that they are serializations of - something that JSON was never designed to do.

Finally, I can understand that you don't want to look up the documentation on a resource, but I honestly don't understand how you came to the conclusion that you "needed to set" date.timezone unless you had done exactly that! Furthermore, receiving a { "date.timezone" : null } tells you nothing about the value space of "date.timezone". Is it a string (e.g. EST, PDT), or is it an integer offset from TC (e.g. 3, -5)? Seeing { "date.timezone" : null } does let you know that there is an attribute names 'date.timezone' but it doesn't tell if you need to set it nor does it tell you what you need to set it to.

> 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