RE: [camp] Use of Cardinality for JSON array attributes

[Jacques Durand <JDurand@us.fujitsu.com>]

I am also in favor of using Boolean constraints whenever possible, which is the case here I think.
To address Anish concern (#34):
- "mutable" still sounds clear to me: =false means its value can never change, =true means it can change (under possibly further conditions.) And it is used extensively with that meaning in software engineering.
When "mutable" is true, you can still have (renaming your "Server-Changeable, Client-Changeable") :
- Consumer-mutable (true/false)
- Provider-mutable (true/false)
Because Consumer/Provider is in our terminology. Now, it occurs to me that we are still fuzzy about Consumer/Provider: what PaaS roles do they map to precisely? Section 1.5 needs be sharper (that’s probably another issue).  
We have a clear map in the spec of "consumer" to Application Developer and Application Administrator. But we are not as clear about the Provider role. 
But do we really need " Provider-mutable" (or Server-Changeable)? Do we really care? First, it sounds redundant (which always makes for inconsistency risk): if mutable=true and Consumer-mutable=false, clearly "someone" on the Provider side must be able to modify it. Yet I'd try to avoid getting into "provider rights" because there will likely be several roles / parties with different access rights on the provider side.
So I would stick with just two "mutability" constraints: mutable (true/false) + consumer-mutable (true/false), in additions to "optional" (true/false).
-jacques


-----Original Message-----
From: camp@lists.oasis-open.org [mailto:camp@lists.oasis-open.org] On Behalf Of Alex Heneveld
Sent: Sunday, February 17, 2013 3:41 AM
To: Tom Rutt
Cc: camp@lists.oasis-open.org
Subject: Re: [camp] Use of Cardinality for JSON array attributes


Tom, All-

What about just having a boolean "required" in place of cardinality ?

Where the type is an array it is clear that multiple values might be within the array.  But my read is that the "cardinality" is still either
0 or 1, so the combo of required + type.isArray gives the same information, in a clearer way.  (I also think cardinality >1 could be taken to mean that the _attribute_ might be listed twice, which is not our intention.)

On a related note, I'd like to see the "mutability" attribute be made a boolean (in 5.2.2) rather than having values "immutable" and "mutable".  
Probably change the name of the field to be "mutable" rather than "mutability".

So 5.2.{1,2,3} would now be "Required", "Mutable", and "Writeable", all booleans, nice and simple and consistent.

--A


On 17/02/2013 05:06, Mr. Tom Rutt wrote:
> For some reason I could not get access to raise a new Jira issue.
>
> I am sending this email for discussion before a formal issue is raised.
>
> There are several attributes defined with an array type (e.g, String[] 
> . Link[])
>
> These attribute definitions have various cardinality values, 
> including, 1, 0..1, or 0..*
>
> It makes no sense for an array attribute to have cardinality 0..*, for this implies multiple arrays in the JSON serialization.
>
> In the case of 0..1 cardinality, Is there a difference in having an array present with 0 elements, versus not having the array present?
>
> In the case of 1 cardinality, is it allowed to have an array with 0 elements present for its serialization?
>
> There does not seem to be a way to specify that an array should not be present in the serialization with zero elements.  What is the difference between no attribute in the serialization, verses an array attribute with no elements?
>
> Proposal:
>
> Lets make the cardinality property of an attribute express the actual semantics of presence.
>
> If the cardinality is 1 it should imply that the attribute is always present, and sent as a basic type value.
>
> If the cardinality is 0..1, it should imply the attribute may be present, and if present is sent as a basic type value.
>
> If the cardinality is 1…*, it should imply that the attribute is 
> alwasy present and sent using an JSON array.  The type in the 
> definition should be the base type (e.g, change Link[] to Link in the 
> definitions of type)
>
> If the cardinality is 0..1, it should imply that the attribute may or 
> not be present,  If present it is sent using a JSON array. It could be 
> constrained to not send empty arrays. The type in the definition 
> should be the base type (e.g, change Link[] to Link in the definitions 
> of type)
>
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php