Re: Slots and the RIM

[Len Gallagher <LGallagher@nist.gov>]

All,

Michael Joya's email is important because it hits directly on a
philosphical difference among participants that I think is the basis of
much of the disagreement we've had since the beginning of this project.

If Michael's suggestion is adopted, then "Slot" becomes a subtype of
IntrinsicObject. Thus it becomes a first class object and MUST inherit all
of the baggage of such objects. It particular it MUST have a UUID that is
visible to the rest of the world! 

Slots were created as an alternative for Classification (see RIM Section
11.4.2, lines 771-794, pages 35-36), because some of us have been arguing
for some time that the RIM has far too many first class objects, especially
Classification, and they're carrying around too many unnecessary
requirements and other baggage from their supertypes.

Slots were designed to be an "attribute" of a RegistryEntry instance, not a
stand alone object. But a slot is a complex attribute, with a name, a type,
and a list of values -- but not necessarily an independent object identifier!

For those of you of my era -- a slot is nothing more than a named and typed
COBOL repeating group, i.e. a set of trailer records physically attached to
a master record. And as such it can be viewed as an attribute of
RegistryEntry. Note that in Figure 1 of RIM, line 274, page 9, the Slot
class is dependent, i.e. black diamond, on RegistryEntry. This is as it
should be.

If I stay active in this project in the future, you will find me arguing
that the Slot notion should be adopted for several other of the classes
that are now stand-alone  objects. In particular, I think that
Classification instances, ExternalLink instances, and ExternalIdentifier
instances would all better serve our purposes if they were modeled as
special kinds of Slots instead of as first class, stand-alone objects.

In fact, I might argue that we don't need to support Slots directly, but
instead we should use the Slot notion to model some of these other Classes
that are logially dependent upon RegistryEntry instances.

-- Len



At 08:06 PM 4/11/01 , Michael Joya wrote:
>I have two points to make regarding slots that the team may want to look at 
>during the next revision.
>
>1.  I've looked around in the RSS and RIM and I can't find a reason why Slot 
>wasn't included into the RIM diagram on . Not only is it absent in this 
>model, but its syntax in the DTD is questionable.
>
><!ELEMENT Value (#PCDATA)>
><!ELEMENT ValueList (Value*)>
><!ELEMENT Slot (ValueList?)>
><!ATTLIST Slot name CDATA #REQUIRED
>               slotType CDATA #IMPLIED>
>
>  While I realize that this is in line with the ObjectManager elements, it 
>does not fit with the rest of the RIM elements, which use a scheme of 
>inherited attributes using entities. Why not do:
>
><!ELEMENT Slot (Value*)>
>
>  It's logically equivalent and eliminates the extra element. Further, I'd 
>propose that Slot is an intrinsic object. (Wrong?) Whereever it fits into 
>the RIM though, it looks as like it should use the same scheme of inherited 
>attributes as the other RegistryObjects do. The following would occlude the 
>'name' attribute and would promote Slot to IntrinsicObject status.
>
><!ATTLIST Slot %IntrinsicObjectAttributes;
>               slotType CDATA #IMPLIED>
>
>
>2. In the table under Section 10.1.1 "Pre-defined Association types". A 
>better description is needed for "RelatedTo" because it is equivalent to the 
>one for "InstanceOf". This whole table really needs to be looked at, because 
>"Supercedes" and "Superceded" are really just two roles for the same 
>bi-directional association, not two types of their own.
>
>
>
>-- 
>// Michael Joya
>// XML Global Research and Development
>// 1818 Cornwall Ave. Suite 9
>// Vancouver, Canada
>// 604-717-1100x230
>
>------------------------------------------------------------------
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org

**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************