Subject: Slots and the RIM
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
Powered by
eList eXpress LLC