OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [regrep] [regrep - RIM draft 02 comment] Compendium

Diego Ballve wrote:

> Farrukh Najmi wrote:
>> Richard Martell wrote:
>>> 5 [ADVISORY] In 2.8.1 perhaps change values to type Set<LongName>
>>>   instead of Bag, since duplicate values don't appear to be meaningful
>>>   in this context.
>> Duplicate for values of a Slot do make sense. For example lets say 
>> the Slot  values store the Gender of each student in a class. I know 
>> it is a dumb example but thats the best I can think of at present. 
>> Suggest no change.
> Set, Bag or Sequence? I'd rather have sequence there, since it is more 
> powerful than Set or Bag (i.e., you can represent a Set or a Bag in a 
> Sequence but not the other way; you can randomize the order of an 
> ordered collection after you get it, but it might not be possible to 
> reorder an unordered collection to the same order it had on creation 
> time).


Diego makes an excellent point. Set or Bag do not maintain order but 
Sequence does and sequence is often important in Slot values. BTW here 
is a brief definition borrowed from [1] of each in case it is not clear:

Set: An object of class *set of* /X/ holds an unordered collection of 
objects of class /X/ with duplicates prohibited.

Bag: An object of class *bag of* /X/ represents a similar collection 
except that duplicates (and multiple instances in general) are permitted.

Sequence: An object of class *sequence of* /X/ is like a *bag of */X/ 
except that it is ordered, so we can enquire what value is at a 
particular position in the sequence (just like indexing into an array).

[1] http://www.eschertech.com/tutorial/chapter2/class_collection.htm

I propose we accept teh change to use Sequence instead of Bag or Set in 
draft 03

> We have discussed this about a year ago, I think, and by that time the 
> use-case I had was that my value was longer than LongName, so I 
> created extra logic in the client to break the value into many 
> LongName (there's a flaw for searches, for instance, but anyway). For 
> that I needed the registry to keep the order and not to return the 
> objects in random order.
Order is important for Slot values in many cases (including one above) 
and does not hurt where it is not important.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]