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

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

On 02/17/2013 05:41 PM, Tom Rutt wrote:
> ________________________________________
> From: Alex Heneveld [alex.heneveld@cloudsoftcorp.com]
> Sent: Sunday, February 17, 2013 12:41 PM
> 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.)
>
> <ter>  are there any cases where we want to constrain that an array attribute must have at least one member of the array if the array is present?
>
> Is it always the case that an JSON array attribute can be present with zero members?
>
> Are there any cases where there would be an upper constraint on the number of members for a JSON array?
>
> My proposal uses the cardinality to express such constraints on the JSON array members.
>
> JSON does not allow multiple attributes with the same name at a given level.

In the JSON spec it is a SHOULD NOT and subject of issue 
https://tools.oasis-open.org/issues/browse/CAMP-50

> It is my view that JSON array is just a seriailzation optimization for multiple occurences of an attribute type.

WRT JSON, arrays are not optimization for multiple occurrences. Unlike 
attributes (which are unordered) array item position is relevant.

-Anish
--

> If we were to have an abstact model which could map to other platforms, (e.g, in XML arrays are just serialized as multiple occurences of the base type attribute.
>
> I do not think that array is a type in JSON, just a seriailzation convention.
>
> Tom
>
> 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