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=31940#action_31940 ] 

Adrian Otto commented on CAMP-32:
---------------------------------

In the course of acting as a CAMP implementer, Gil has raised a valid question of whether he should make an effort to format his JSON output in a particular way. This is a question of style, in an aim to be consistent with other implementations in the future.

If we were using XML, then we would want him to include nulls. Because we are using JSON, there is considerable stylistic precedent to omit null values. Because JSON does allow for the expression of null values, it would be unwise to prohibit such expression, but we should provide guidance to inform the implementer what we expect most to do.

Note that a value of null and a value of 0 are not equal, and have different representations in JSON serialization. We definitely want to leave any zero value attribute alone, regardless what we decide to do with null values.

I am willing to explicitly require that valid JSON syntax must be used, and call out a reference that defines what valid syntax is. I am unwilling to *require* implementers to omit nulls, or empty arrays.

If we decide to require "JSON Patch" support in addition to a more simple HTTP PATCH, then we need not make an exception for nulls here. That would simplify my suggestion here to:

        1) Servers SHOULD NOT express attributes with empty arrays or null values. Omitting null values and empty arrays is RECOMMENDED.
        2) Servers and clients receiving empty arrays or null values SHOULD ignore them.

This approach allows an implementer to express null values and empty arrays if they have a good reason for departing from prevailing JSON style practices, yet provides clear guidance for them.

> 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]