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


Since there have been no objections to removing composed ids from RIM and
going back to normal UUIDs for all sub-classes of RegistryObject, I will now
work with Sally at her convenience to update RIM to remove composed ids and
revert them back to normal UUIDs.

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


org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
fn:Farrukh Najmi

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

Powered by eList eXpress LLC