Re: [regrep] Proposal: RIM Slot enhancements

[duane@yellowdragonsoft.com]

++1 also.

farrukh - see you tonight at J-One.

Duane

> First a warm welcome to Diego and Republica as a member of the ebXML
> Regisry TC.  We will really benifit from the practical user experience
> and perspective that you will bring to the team.
>
> Diego Ballvé wrote:
>
>>Some enhancement ideas regarding RIM Slots have came up during
>>regrep-cc-review work but since they are general improvements
>>to RIM I'm proposing them here. The current definition of RIM
>>Slot [1] has been also pasted below.
>>
>>The enhancements:
>>
>>1) The first point is to change the Slot.value attribute to an
>>"Ordered" Collection of LongName. A RIM Slot can have n values,
>>but currently the specification does not enforce the values'
>>order.
>>
> ++1 This is a very important feature lacking in Slots today.
>
>>
>>2) Once (1) is accepted, we could define some special values
>>for attribute slotType and extendend the semantics of Slot.
>>Based on the Slot.slotType, we could then decide wether to
>>handle Slot.values as:
>>- only 1 'short' string (values.size must be 1)
>>- many 'short' strings (1 per value)
>>- a 'long' string (catenate all values)
>>- many 'long' strings (catenate all values and tokenize)
>>
> I understand the rationale and need for above and agree with them. I am
> a little unsure what is the right solution. One possibility is to should
>  consider specializing Slots into multiple sub-types like  SmallSlot,
> MediumSlot, LargeSlot with LargeSlot supporting the infinite size by
> having using concatenation.
>
> IMO, we should consider Slot enhancement for V3 rather than post V3. I
> would be eager to work with you to spec the changes that you propose in
> detail for V3.
>
> Thanks for this valuable suggestion.
>
>>
>>These changes would allow a Slot to be able to store
>>more than a Collection of LongName, although the initial
>>Collection can still be stored.
>>
>>A negative point might be the searches by Slot value. Would
>>they be able to understand these semantics?
>>
>>Regards,
>>Diego
>>
>>--------------------------------------------
>>Diego Ballve
>>Product Manager
>>Republica Corp., Products
>>Survontie 9, 40500 Jyväskylä, Finland
>>E-mail: diego.ballve@republica.fi
>>http://www.republica.fi/
>>http://www.x-fetch.com/
>>
>>
>>
>>[1] RIM Slot definition in RIM 2.5 Spec [2]
>>
>>764 7.7 Class Slot
>>765 Slot instances provide a dynamic way to add arbitrary attributes to
>> RegistryObject 766 instances. This ability to add attributes
>> dynamically to RegistryObject instances enables 767 extensibility
>> within the information model.
>>768
>>769 A RegistryObject may have 0 or more Slots. A slot is composed of a
>> name, a slotType 770 and a collection of values.
>>
>>774 7.7.2 Attribute name
>>775 Each Slot instance must have a name. The name is the primary means
>> for identifying a 776 Slot instance within a RegistryObject.
>> Consequently, the name of a Slot instance must be 777 locally unique
>> within the RegistryObject instance.
>>
>>778 7.7.3 Attribute slotType
>>779 Each Slot instance may have a slotType that allows different slots
>> to be grouped together.
>>
>>780 7.7.4 Attribute values
>>781 A Slot instance must have a Collection of values. The collection of
>> values may be empty. 782 Since a Slot represent an extensible attribute
>> whose value may be a collection, therefore a 783 Slot is allowed to
>> have a collection of values rather than a single value.
>>
>>[2]
>> http://www.oasis-open.org/committees/regrep/documents/2.5/specs/ebrim.2.5.pdf
>>
>>
>>
>>
>>
>>
>>You may leave a Technical Committee at any time by visiting
>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php
>>
>>
>>
>>
>
>
>
> You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php