[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: New ObjectType Hierarchy (ebRIM Change)
I assumed that, too. Assuming is baaad. Thanks for making it clear. And +1 to calling it an extension, not a change to standard RIM. Diego > -----Original Message----- > From: Chiusano Joseph [mailto:email@example.com] > Sent: Monday, July 07, 2003 6:46 PM > To: Farrukh Najmi > Cc: Diego Ballvé; CCRev > Subject: Re: New ObjectType Hierarchy (ebRIM Change) > > > Yes - I just had a conversation with Nikola on this very point. The > hierarchy should contain a node for "CCTS", but the "non-CCTS types" > would simply fall under "ExtrinsicObject" (or possibly their own > intermediate node). IOW, we should not prescribe an explicit node for > "non-CCTS types". The picture would now look as follows (please also > note points following picture): > > Object Type > | > RegistryObject > | > RegistryEntry > | > ExtrinsicObject > | | > __CCTS__ all others > | | | > ACC ASCC BCC etc. > > So if (for instance) we created Business Process ObjectTypes in the > future, we could add a "BP" node under ExtrinsicObject and > place the BP > objects under that. > > Secondly: We should not consider this hierarchy an "ebRIM change" as I > described below - rather, it should be considered an "ebRIM extension" > to the base RIM. This way, our "core ebRIM spec" would stop at > ExtrinsicObject and bindings (such as ours) would extend the > core ebRIM. > > Joe > > > Farrukh Najmi wrote: > > > > Minor point which I am sure is consistent with the intent > of the picture.... > > > > I assume Non-CCTS will not be an explicit node in > ObjectType tree and should > > therefor be shown as <Other Non-CCTS types>.