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