Re: New ObjectType Hierarchy (ebRIM Change)

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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>.
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Monday, July 07, 2003 11:13 AM
> To: Farrukh Najmi
> Cc: Diego Ballvé; CCRev
> Subject: New ObjectType Hierarchy (ebRIM Change)
> 
> Team,
> 
> Based on all input, the following represents our new ObjectType
> hierarchy:
> 
>           Object Type
>                |
>          RegistryObject
>                |
>           RegistryEntry
>                |
>          ExtrinsicObject
>          |             |
>      __CCTS__        Non-CCTS
>     |    |   |             |
>    ACC ASCC BCC etc.  (all others)
> 
> This would be considered an ebRIM change. Please let me know if you have
> any questions or comments.
> 
> Thanks,
> Joe
> 
> Farrukh Najmi wrote:
> >
> > +1 on Diego's suggestion.
> >
> > One other minor correction is that ExtrinsicObject is under
> > RegistryEntry in ebRIM.
> >
> > BTW I am on vacation and infrequently online.
> >
> > --
> > Regard,
> > Farrukh
> >
> > Chiusano Joseph wrote:
> >
> > >[Would like Farrukh and Nikola's input]
> > >
> > ><Quote>
> > >Though I'd add one more layer, the "CCTS Objects" or whatever name we
> > >decide for, between Extrinsic Object and ACC/BCC/etc.
> > ></Quote>
> > >
> > >I can definitely see the value in that. So our hierarchy would look as
> > >follows (I guess the "other" Extrinsic Objects would be "Non-CCTS", but
> > >am open to better terms):
> > >
> > >Object Type
> > >     |
> > >RegistryObject
> > >  |          |
> > >Registry  Extrinsic
> > > Entry     Object    etc.
> > >         |        |
> > >       CCTS    Non-CCTS
> > >    |   |    |         |
> > >   ACC ASCC BCC etc. (all others)
> > >
> > >Farrukh and Nikola, what do you think of this?
> > >
> > >Joe
> > >
> > >Diego Ballvé wrote:
> > >
> > >
> > >><Quote>
> > >>In a nutshell, Diego has taken all of the CCTS object types (12 in all)
> > >>and classified them as follows:
> > >>
> > >>Object Type
> > >>     |
> > >>CCTS Objects
> > >> |   |    |
> > >>ACC ASCC BCC etc.
> > >>
> > >>Farrukh and Nikola have proposed:
> > >>
> > >>Object Type
> > >>     |
> > >>RegistryObject
> > >>  |          |
> > >>Registry  Extrinsic
> > >> Entry     Object    etc.
> > >>         |   |    |
> > >>        ACC ASCC BCC etc.
> > >>
> > >>Farrukh and Nikola's approach was accepted on our TC call yesterday. Is
> > >>everyone (especially Diego) comfortable with this representation of Core
> > >>Component Object Types?
> > >></Quote>
> > >>
> > >>Comfortable, yes. Though I'd add one more layer, the "CCTS Objects" or
> > >>whatever name we decide for, between Extrinsic Object and ACC/BCC/etc.
> > >>
> > >>Reason is to separate CCTS ExtrinsicObjects from other specs
> > >>ExtrinsicObjects that might appear later.
> > >>
> > >>Diego
> > >>
> > >>Ps. Sorry for missing the TC calls, but the time is not so good for
> > >>me. I could attend if I would be really needed.
> > >>
> > >>You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_
> workgroup.php
> > >>
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard