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] Proposal: RIM Slot enhancements


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
>
>
>  
>




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