<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
