[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] Remove RegistryEntry class
No objections - I say cut it. I made the same observation in my "Fine-Grained Artifacts TN" that I gave to a federal audience a few weeks ago. Kind Regards, Joseph Chiusano Booz Allen Hamilton Strategy and Technology Consultants to the World > -----Original Message----- > From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] > Sent: Tuesday, December 28, 2004 2:57 PM > To: regrep@lists.oasis-open.org > Subject: [regrep] Remove RegistryEntry class > > > As I work my way through regrep-rim-3.0-draft-01 document I > see another area where we have unnecessary complexity that is > hard for us to describe to our intended reader. > > I am talking about the RegistryEntry class. Much > functionality from this class has bubbled up to > RegistryObject class over the years. > All this class provides at this point is the expiration and stability > attributes: > > <complexType name="RegistryEntryType"> > <complexContent> > <extension base="tns:RegistryObjectType"> > <attribute name="expiration" type="dateTime" use="optional"/> > <attribute name="stability" type="tns:referenceURI" > use="optional"/> > </extension> > </complexContent> > </complexType> > <element name = "RegistryEntry" type = "tns:RegistryEntryType" > substitutionGroup="tns:Identifiable" /> > > There is little rhyme or reason that we can provide for why > some classes are derived from RegistryEntry and why others > are derived from RegistryObject. I propose we simplify the > model and remove the RegistryEntry class all together. We can > still define expiration and stability attributes as canonical > Slots on the RegistryObject class so that any object can have > stability and/or expiration defined in a standard way if needed. > > BTW for what its worth these attributes have not been used > much in my experience with various deoployments of freebXML Registry. > > I have long felt that the RegistryEntry class is unnecessary > and should be removed. Does anyone have any objections to > removing this additional layer in our model? > > -- > Regards, > Farrukh > > > To unsubscribe from this mailing list (and be removed from > the roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/regrep/members/le ave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]