[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [camp] Use of Cardinality for JSON array attributes
slight clarification inline
________________________________________
From: camp@lists.oasis-open.org [camp@lists.oasis-open.org] On Behalf Of Tom Rutt [TRutt@us.fujitsu.com]
Sent: Tuesday, February 19, 2013 6:07 PM
To: Anish Karmarkar; camp@lists.oasis-open.org
Subject: RE: [camp] Use of Cardinality for JSON array attributes
Based on this discussion I have a few further questions to be discussed?
If the property is changed from "cardinality" to a boolean "required" we need to clarify that
<ter. if the required property value is "false" then </ter>
the message is valid both with and without the attribute present.
It is not conformant for a receiver to reject the message if the attribute is present.
If we go this route it still leaves the question: are there any upper or lower bounds on the array sizes for attributes with array types?
In particular:
can every array attribute be present in a message with no members (i.e., empty)?
are there any array attributes which have upper bounds on array size?
If we no not need to be able to express such constraints on array bounds, the proposal from Alex will suffice.
Tom
________________________________________
From: camp@lists.oasis-open.org [camp@lists.oasis-open.org] On Behalf Of Anish Karmarkar [Anish.Karmarkar@oracle.com]
Sent: Monday, February 18, 2013 7:11 AM
To: camp@lists.oasis-open.org
Subject: Re: [camp] Use of Cardinality for JSON array attributes
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
>
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]