Next in thread → Next in month →

RE: New ObjectType Hierarchy (ebRIM Change)

From
=?iso-8859-1?P?Eiego_Callv=F9?=
Date
2003-07-08T06:38:33+00:00
ID
Thread
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:]
> 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>.
Next in thread → Next in month →