[regrep] Action needed: Need resolution of composed id issue

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

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

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard