[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=31984#action_31984 ] 

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

"If we must" is open to debate. If the group doesn't think there is a big enough interop problem here to warrant saying anything, then we don't have to say anything.

For my part, I think trying to convey "the full structure" of a resource by serializing null attributes and empty arrays is the wrong thing to do. Your Twitter API example is illustrative. The fact that I know that there is such an attribute as "in_reply_to_status_id" is useless information. Unless I read the documentation on the API, I have no idea what it means and what, if anything, I should do with it. Once I read the documentation, the actual presence of the attribute is irrelevant because I know that the non-appearance simply means that the attribute has no value.

I would like to proceed on my proposed language that says that clients and servers SHOULD NOT serialize null values and empty arrays. My second choice would be to remain silent on the issue. My last choice would be to recommend or require that nulls and empty arrays be serialized.

> 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