[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [REVISITING]Re: [regrep-cc-review] Cardinality - Was: CCTS Spec RIM Mappings Revisited: [S8] to [S18]
Does anyone have any comments (positive or otherwise) on the proposed handling of Cardinality below (beginning with "Yes - I propose that")? Thanks, Joe Chiusano Joseph wrote: > > <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 > > ------------------------------------------------------------------------ > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]