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


Oops,

Among the two issues I cited:

>-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.

Only the second is relevant. The first issue should have been taken out as I
found that we could use a composed id consisting of the
registryObject, identificationScheme and value attributes.

Note we still have a problem with composed ids. Its just that insteda of two
identified problems we have only 1.

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

--
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


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


Powered by eList eXpress LLC