OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Summary of proposed RIM changes



Thanks for the Summary Farrukh -- you've done a great job of identifying 
the things we discussed and found some common ground on.

I demur somewhat from two things you said:

1) There's an implication that we now agree completely on how 
classifications are handled. Instead, the issue of how to support 
classifications for schemes whose nodes do not exist in this Registry is 
still an issue. However, we did discuss this topic and see an approach that 
may be acceptable to both points of view. That possible approach is not 
reflected in either of the diagrams that were distributed, although it 
wouldn't necessarily change anything that is visible in those diagrams.

2) The Executive Summary states that roles played by all classes are the 
same as in the existing specification. Instead, I think it's more accurate 
to say that the roles of Associations, Classifications, and Slots are 
potentially much more general than they currently are. In particular, 
Classifications are proposed to be possible on any RegistryObject instead 
of just on RegistryEntry and the sourceObject of an Association could be 
any RegistryObject instead of just RegistryEntry. I think the issue now 
becomes "if this role expansion is supported by the model, how much of it 
becomes required of every conforming implementation?".

I'm going to send a separate email explaining how I had to change my 
thinking about some terms and concepts in order to feel more comfortable 
with what we are proposing.

-- Len


At 08:48 AM 8/9/01, Farrukh Najmi wrote:
>Here is a quick summary of proposed changes to the best of my
>recollection (Len, please correct if I missed anything):
>
>-Replace all interfaces with classes to make it clearer what are
>attributes Vs. relationship methods. This is aimed at making the RIM
>clearer and easy to understand (at the expense of being less object
>oriented).
>
>-Move several classes up the hierarchy in RIM Fig 2 to reduce number of
>attributes they carry. We referred to this as putting them on a diet
>plan.
>     -Move all sub-classes of IntrinsicObject (except Package) under
>RegistryObject.
>     -Move Package under RegistryEntry (sibling of ExtrinsicObject)
>     -Eliminate IntrinsicObject all together
>     -Eliminate Versionable and moved majorVersion/minorVersion as
>attributes in RegistryEntry
>
>-Move support for packaging, external linking, external identification,
>classification, slots etc. (proposed term dynamic metadata) from
>RegistryEntry up to RegistryObject. This now makes RegistryObject the
>central class in RIM Fig 2.
>
>-Move objectType attribute from RegistryEntry to RegistryObject
>
>-Add some new classes:
>     -Add ClassificationScheme as a sub-class of RegistryEntry (and
>sibling of Package and ExtrinsicObject). This class is expected to
>replace root level ClassificationNodes in a classification scheme. This
>allows for scheme specific metadata to be defined in one class for a
>scheme. Rest of classification stuff is unchanged.
>
>-Proposed supporting multiple Organizations related to a RegistryObject
>by way of an Association class. Previously only one was allowed (SO).
>Now we can have as many as we want with initial focus on Approving
>Organization (Is that right Len?)
>
>Executive Summary
>--------------------
>
>The RIMs cast of characters (classes) does not change under the joint
>proposal, other than one new member ClassificationScheme. The roles
>played by them are the same and their relationships to each other are
>the same. What changes under the proposal is that they carry fewer
>attributes.
>
>To use a people analogy from our TC, after the proposed changes we will
>be the same people, play the same roles, and have the same relationships
>with each others. However, we would all  be slimmer, more agile and
>hopefully better looking :-)
>
>--
>Regards,
>Farrukh
>
>
>"Munter, Joel D" wrote:
>
> > Can you please provide a short summary of the changes/compromises that
> > were made.  This would help us greatly.Thanks, Joel
> > -----Original Message-----
> > From: Lisa Carnahan [mailto:lisa.carnahan@nist.gov]
> > Sent: Wednesday, August 08, 2001 12:38 PM
> > To: regrep@lists.oasis-open.org
> > Cc: tom Rhodes
> > Subject: Call Tomorrow
> > Hello All,
> >
> > As many of you know, throughout the ebXML effort Len Gallagher from
> > NIST had raised serious concerns regarding the ebXML information model
> > and services.  Most of these issues were raised prior to our ebXML
> > meeting in Vancouver.  At that meeting, the committee decided to defer
> > resolution on many of these issues until after Phase I.  So here we
> > are in Phase II.
> >
> > As those who attended the Vancouver meeting know, Farrukh Najmi (and
> > others) had serious concerns regarding many of Len's issues.    It
> > became apparent to me that some benefit may be derived if I put Len
> > and Farrukh  in a room for a day or so to discuss Len's issues.   So
> > we did just that.
> >
> > Last week Len, Farrukh, Nikola Stojanovic, and I met for a day and a
> > half to discuss Len's recurring issues.  The meeting was extremely
> > productive in that many issues were resolved to all parties'
> > satisfaction (sort of).   The attached file represents two proposals
> > for changing the information model and inheritance diagrams for the
> > RIM.  (We additionally started a list of bugs that were identified
> > during the discussion.  I'll provide that in a separate message.)
> >
> > Please recognize that the attached documents do not represent
> > consensus of the OASIS/ebXML Registry TC.  Currently the attached
> > documents are based on the opinions of 3 TC members.  (My role was
> > more of a facilitator than a TC member.)  We will discuss these
> > proposals during the conference call tomorrow.  These proposals will
> > be accepted only if we achieve positive consensus within the TC.
> >
> > I have a number of other items for the agenda; I'll try and send you
> > email regarding them before the meeting.
> >
> > Call-in information:  NOTE: THIS NUMBER IS DIFFERENT THAN THE LAST
> > CALL.
> >
> > CALL DATE:         AUG-09-2001  (Thursday)
> > > CALL TIME:         04:00 PM EASTERN TIME
> > > DURATION:              2 hr
> > > USA Toll Free Number: 888-566-5920
> > > USA Toll Number: +1-630-395-0252
> > >  PASSCODE: 13852
> > >  LEADER:            Ms Lisa Carnahan
> >
> > --lisa

**************************************************************
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
**************************************************************



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC