OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

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

I don't understand the issue about interoperability. Null values or empty arrays are straight JSON, so every JSON implementation supports it, no? At the JSON level, there are no semantics attached to 'null' other than it denotes absence of a value. So, a parameter with 'null' value means the structure has the parameter (as opposed to a structure that doesn't) and that the parameter value is absent. Analogous for empty array values.

I get the legibility argument (which is negligible unless there is a large number of 'null' values) and I get the bandwidth argument. I also get Adrian's culture argument. Still, I feel being explicit about the structure of a resource is more valuable than all of these taken together.

Also, I don't think I argue for JSON as a schema language. I argue for JSON to represent the relevant data. Again, referring to an actual use case: if a PHP PC has its "date.timezone" configuration variable not set ("null"), I want to see it, because it means I'll have to take action and set it. I don't want to have to look up documentation to see what the default is or whether this configuration is actually exposed by the PC or not (which *is* a very relevant difference).


> 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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]