Re: [regrep-cc-review] Cardinality - Was: CCTS Spec RIM Mappings Revisited: [S8] to [S18]

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
I wonder if we really need 2 Slots (my previous impl uses 2) or 1 Slot
and the .. representation would be enough (is there any standard for
this 'grammar'?):

Cardinality = (0 | PositiveInteger) .. (* | PositiveInteger)
I would go for '*' as many, instead of 'r' as repetitive, although
"optional, repetitive" and "mandatory, repetitive" sounds better. :)
'*' is commonly associated with many, or any. 'r' is not that obvious.

Also, you might need to represent maxOccurs="2" and not only repetitive.
The proposed approach doesn't specify if (0,2) is allowed. If it is, ok
then. It just has to be specified.
</Quote>

Yes - I propose that:

(1) We enhance RIM to add 2 attributes to the Slot class called
"MinimumOccurrences" and "MaximumOccurrences" 

(2) "MinimumOccurrences" would be of type "Integer" (i.e. would be 0 or
1 in most cases)

(3) "MaximumOccurrences" would be of type "Integer", but we would allow 
"*" to represent "unbounded". The CCTS only specifies maximum
occurrences as "repetitive", rather than a concrete number. However, I
think that it would be fine for us to allow implementations to specify a
concrete number of maximum occurrences as well, and we can still satisfy
the CCTS requirement of "repetitive" by allowing "*".

- Our RIM Integer datatype is 4 bytes (which allows a maximum value of
1G), so that should be more than enough to represent realistic
scenarios.

- If we cannot specify type of "Integer" with "*" allowed as a value, we
could always specify that the maximum possible value (2^32) should be
used to represent "unbounded"

Any thoughts?

Joe

Diego Ballvé wrote:
> 
> > Chiusano Joseph wrote:
> >
> > I just had a thought regarding cardinality on RegistryObjects
> > vs. Slots.
> > The quote below addresses cardinality on RegistryObjects:
> >
> > <Quote>
> > Cardinality - represent using a Slot that indicates the maximum number
> > of occurrences of the Core Component Property (like W3C Schema's
> > "maxOccurs" facet).
> >
> > QUESTION: How should we represent "mandatory/optional" for attributes,
> > as specified in the CCTS? We could have "minOccurs" and "maxOccurs"
> > Slots for all entities, in which:
> >
> > (0,1) indicates optional (i.e. minOccurs="0", maxOccurs="1");
> > (1,1) indicates mandatory;
> > (0,r) indicates optional, repetitive
> > (1,r) indicates mandatory, repetitive
> >
> > This approach would allow us to represent both the optional/mandatory
> > characteristic and cardinality characteristic for a given entity using
> > the same set of attributes.
> > </Quote>
> >
> > However, in many cases in CCTS we have cardinality on slots.
> > This was an
> > issue that Diego brought up early on:
> >
> > <DiegoQuote>
> > - 0..* and 1..* properties are harder to handle if the
> > possible values are not known beforehand. How to name the
> > slot then??
> > </DiegoQuote>
> >
> > Let's revisit this earlier debate on how to represent cardinality with
> > slots. Any thoughts?
> 
> I wonder if we really need 2 Slots (my previous impl uses 2) or 1 Slot
> and the .. representation would be enough (is there any standard for
> this 'grammar'?):
> 
> Cardinality = (0 | PositiveInteger) .. (* | PositiveInteger)
> 
> I would go for '*' as many, instead of 'r' as repetitive, although
> "optional, repetitive" and "mandatory, repetitive" sounds better. :)
> '*' is commonly associated with many, or any. 'r' is not that obvious.
> 
> Also, you might need to represent maxOccurs="2" and not only repetitive.
> The proposed approach doesn't specify if (0,2) is allowed. If it is, ok
> then. It just has to be specified.
> 
> And about my previous quote, it was regarding storage of composite
> properties (SupplementaryComponent definitions in that case) in Slots,
> which has been dropped. Also, Slot values'max length is a very restrictive
> feature. I wish we could get rid of that. It won't stop our work, though.
> 
> Diego
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard