[RIM Issue] Do we need id attribute for composite instance withincomposed instance

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

Thank you Goran and other colleagues for the through review comments you 
have been sending. The vast majority of them have already been 
incorporated in 3.0-draft-02 specs that are being edited at present. In 
some cases I have adviced "No Change" for some comments and given my 
reasons why. Here is another case where I think no change should be made 
to address the comment.

Goran Zugic wrote:

>RIM 3.0 COMMENTS
>===========================================
>  
>
...

>
>8. Line 569	2.6.1 Attribute Summary
>
>   RegistryObject id is needed to support a relationship between a VersionInfo and RegistryObject.
>   
>10. Line 614   2.8.1 Attribute Summary
>
>    RegistryObject id is needed to support a relationship between a Slot and RegistryObject.
>    
>15. Line 1031    5.5.1 Attribute Summary
>
>    RegistryObject (User, Organization) id is needed to support a relationship between a 
>    PostalAddress and RegistryObject.
>    
>    Since a PostalAddress can has Slots defined, to support that relationship 
>    the PostalAddress needs an id attribute as well. Slots are in relations with 
>    RegistryObjects through their UUIDs.
>    
>    
>
>16. Line 1054   5.6.1 Attribute Summary
>
>    RegistryObject (User, Organization) id is needed to support a relationship between a 
>    TelephoneNumber and RegistryObject.
>    
>    
>
>17. Line 1074   5.7.1 Attribute Summary
>
>    RegistryObject (User, Organization) id is needed to support a relationship between an 
>    EmailAddress and RegistryObject.
>    
>    Since an EmailAddress can has Slots defined, to support that relationship 
>    the EmailAddress needs an id attribute as well. Slots are in relations with 
>    RegistryObjects through their UUIDs.   
>    
>    
>    
>18. Line 1086    5.8.1 Attribute Summary
>
>    RegistryObject (User) id is needed to support a relationship between a 
>    PersonName and RegistryObject.
>    
>    Since a PersonName can has Slots defined, to support that relationship 
>    the PersonName needs an id attribute as well. Slots are in relations with 
>    RegistryObjects through their UUIDs.
>
>  
>
After some reflection I now recall why in all of above cases the id 
attribute is not included in the respective classes in RIM.
The rationale is that all of these classes are composed within a 
composite class (usually RegistryObject) and the composition relationship
makes it unnecessary to model the id attribute in the composed class in 
a UML model. This is also true for the XML Schema mapping of these classes
from the RIM. I have included the text from regrep-3.0-rim-draft-02 that 
gives a normative description of composed classes below for your reference.

When mapping to SQL however, the id column *is* needed in order to 
enable a relational join across the tables fro the composite and 
composed classes in RIM.
This is a special need for the relational schema binding from RIM and 
IMO should not be reflected in RIM. It is defined in the relational 
schema and that is where I think it belongs.

For this reason I would like to propose we make no change for the above 
comments. Please share your thoughts.

Also comments on the following text would be appreciated but do so in a 
separate thread titled "[RS Issue] Comments on Composed Object Definition".

2.5.2 Composed Object

A RegistryObject instance MAY have instances of other RegistryObjects 
and other classes composed within it as defined in this specification. 
In such a relationship the composing object is refered to as the 
/Composite/ object as defined in section 3.4 of [UML]. The composed 
object is refered to in this document and other ebXML Registry 
specification as /Composed/ object. The relationship between the 
Composite and Composed object is refered as a composition relationship 
as defined in section 3.4.8 of [UML].

/Composition/ relationship implies that deletes and copies of the 
Composite object are cascaded to implicitly delete or copy the composed 
object. In comparison a UML Aggregation implies no such cascading.

The following classes defined by [RIM] are compsed types and follow the 
rules defined by UML composition relationships. The classes are listed 
in the order of their being defined in this document. Note that abstract 
classes are not included in this list since an abstract class cannot 
have any instances.

    *

      InternationalString

    *

      LocalizedString

    *

      VersionInfo

    *

      Slot

    *

      ExternalIdentifier

    *

      Classification

    *

      PostalAddress

    *

      TelephoneNumber

    *

      EmailAddress

    *

      PersonName

    *

      ServiceBinding

    *

      SpecificationLink

    *

      QueryExpression

    *

      NotifyAction

Many thanks.

-- 
Regards,
Farrukh