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: [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:
>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
>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 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
>ExternalIdentifier, Classification, ServiceBinding and SpecificationLink
>These are the two classes that currently use a composed id attribute in
>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.

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