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

[Diego Ballvé <diego.ballve@republica.fi>]

> 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