[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (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=31959#action_31959 ]
Gilbert Pilz edited comment on CAMP-32 at 12/12/12 6:29 PM:
------------------------------------------------------------
This issue is not about optimizing the number of bytes on the wire, it is about interoperability. The fact that we don't agree on the semantics of a JSON 'null' is a clear indication that there are potential interoperability problems here.
You seem to be arguing for the use of JSON as its own schema language. I don't think this is workable. Suppose, for example, that I did a GET on some "unknown" Platform Component Template and got back the following:
{
"type" : PostgreSQL
"uri" : "http://slc03lgx.us.oracle.com/campSrv/PlatformComponentTemplate/23";,
"name" : "MedPostgreSQL",
"description" : "medium-weight PostgreSQL server",
"created" : "2012-11-14T08:33Z",
"tags": []
...
"cache" : null
...
}
I can guess that this is a PCT for a PostgreSQL service. I know that it supports an attribute called "cache". However, I don't even know the type of this attribute let alone itss semantics! It could be a String that describes the amount of in-memory cache allocated to this server, but I have no idea what the units are. It could just as readily be a Link to some other PCT that describes a caching service. The point is, without some other documentation about the "cache" attribute, the fact that I know that this PCT supports this attribute doesn't help me at all.
I completely agree that we are going to need some mechanism whereby a CAMP server implementation can advertise the attributes and semantics of new resource types; CAMP-1 is the issue for this. I don't think forcing CAMP servers to serialize attributes that have no value is the way to address that issue.
was (Author: gilbert.pilz):
This issue is not about optimizing the number of bytes on the wire, it is about interoperability. The fact that we don't agree on the semantics of a JSON 'null' is a clear indication that there are potential interoperability problems here.
You seem to be arguing for the use of JSON as it's own schema language. I don't think this is workable. Suppose, for example, that I did a GET on some "unknown" Platform Component Template and got back the following:
{
"type" : PostgreSQL
"uri" : "http://slc03lgx.us.oracle.com/campSrv/PlatformComponentTemplate/23";,
"name" : "MedPostgreSQL",
"description" : "medium-weight PostgreSQL server",
"created" : "2012-11-14T08:33Z",
"tags": []
...
"cache" : null
...
}
I can guess that this is a PCT for a PostgreSQL service. I know that it supports an attribute called "cache". However, I don't even know the type of this attribute let alone itss semantics! It could be a String that describes the amount of in-memory cache allocated to this server, but I have no idea what the units are. It could just as readily be a Link to some other PCT that describes a caching service. The point is, without some other documentation about the "cache" attribute, the fact that I know that this PCT supports this attribute doesn't help me at all.
I completely agree that we are going to need some mechanism whereby a CAMP server implementation can advertise the attributes and semantics of new resource types; CAMP-1 is the issue for this. I don't think forcing CAMP servers to serialize attributes that have no value is the way to address that issue.
> 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]