[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] Action needed: Need resolution of composed id issue
Registry TC, Please ignore the penultimate paragraph of this email. I'm perfectly capable of speaking for myself. -- Len At 01:45 PM 11/19/01, Farrukh Najmi wrote: >Team, > >As I have been working on SQL Query update and I18N changes for V2 specs >it has become apparent >that the current composed id solution will not work. > >Problems with composed ids >----------------------------- >Some issues found are: > >-With the I18N proposal we have multiple names. But name is used as a >composed >field in ExternalIdentifier's composed id. > >-In RIM binding to SQL schema, how do we model references that do not >have normal ids and instead use a composed id. How do these >references get stored persistently in the SQL schema. > >I went and took an inventory in Fig 1 of those classes that are composed >within a RegistryObject or one of its sub-classes and are sub-classes >of RegistryObject. I found 5. (AuditableEvent, ExternalIdentifier, >Classification, ServiceBinding and SpecificationLink) Note that I am not >including Slot since it is not a RegistryObject sub-class. > >AuditableEvent >---------------- >AuditableEvent being a composition was a known mistake and I fixed Fig 1 >so it is no longer shown as composition. Instead it is shown as a UML >association. Note that this association does not use a RIM Association >class so there are no issues with extramural Associations and >confirmation. > >ExternalIdentifier, Classification, ServiceBinding and SpecificationLink > >------------------------------------------------------------------------ > >These are the two classes that currently use a composed id attribute in >RIM. > >Addressing Issues related to composed Ids >------------------------------------------- >Note that given the problems with composed id recently identified, we >have to do something. Inaction is not an option. > >We could deal with the two compositions cases in one of the following >two ways: > >1. Make the two classes (ExternalIdentifier and Classification) have >UUIDs even though it is not necessary. Note that this >is how things used to be until RIM 1.1. > >2. Alternatively, make the 4 classes not be sub-classes from >RegistryObject. Instead >they would be entity classes like TelephoneNumber etc. The result would >be that they could not support dynamic metadata. The biggest casualty >would be the inability to classify classifications. > >I am sure that (2) has elements of one or more of Len's proposals and >likely to be attractive to Len. However, it has more risk associated >with it >as we would be changing the RIM hierarchy. > >(1) on the other hand is completely risk-free. All it involves is >removing the "Inherited Attribute id" sections as well as the definition >of composed ids from RIM. > >I am currently leaning towards solution (1). I have discussed this issue >with Len and I have the impression that he can live with (1). > >We need a decision ASAP on this. Please speak up if you disagree with >(1) or have a suggestion we did not consider. > >-- >Regards, >Farrukh > ************************************************************** 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