RIM 3.0 Comments

["Goran Zugic" <gzugic@ebxmlsoft.com>]

These are my RIM 3.0 comments. I'll send RS 3.0 comments next week.

 

Regards,

Goran

RIM 3.0 COMMENTS
===========================================


1. Copyright year 2004 should be changed.



2. Table of Contents

   Line 187    "6.2.3 Attribute accessURI" duplicated

   
   
3. "Attribute Summary" for any class could have attributes' descriptions as sub-sections 
   under "Attribute Summary". For example, now it is
   
         7.7 Class Notification
           7.7.1 Attribute Summary
           7.7.2 Attribute subscription
           7.7.3 Attribute registryObjectList
           
    This could be changed to
    
         7.7 Class Notification
           7.7.1 Attribute Summary
             7.7.1.1 Attribute subscription
             7.7.1.2 Attribute registryObjectList   


             
4. Can we add the "Repository" to the official "OASIS/ebXML Registry" name 
   because it is the main difference between UDDI Registry and ebXML Registry and Repository
   standard. At the same time, the Repository component is one of the main advantages over 
   the UDDI Registry.


   
5. New Classes such as Registry, Federation, Subscription etc., are not added to the 
   "Figure1: Information Model Relationships View" (Page 13, Line 407)


   
6. I am not sure, but the names of the canonical ClassificationSchemes sound too generic to me.
   Can we make them more specific as ebXML Registry and Repository reserved words.
   For example, RIMObjectType or something like that.

   

7. Line 563    It should be "... versionInfo attribute ..." instead of "... objectType attribute ...".



8. Line 569	2.6.1 Attribute Summary

   RegistryObject id is needed to support a relationship between a VersionInfo and RegistryObject.
   


   
9. Line 590    2.7.1 Attribute Summary

   id and home should not be in the attribute list because they are already defined in the Identifiable 
   that is the super class of the ObjectRef.

   
   
10. Line 614   2.8.1 Attribute Summary

    RegistryObject id is needed to support a relationship between a Slot and RegistryObject.



11. stability, expiration and userVersion attributes are completely removed from all 
    former RegistryEntry classes. Does it mean that we will not support for example 
    stability feature for the RepositortItems (dynamic, static, etc.), etc.? 
    Some of the previous notes mentioned that they can be defined by Slots. Are we going to 
    formalize it in the RIM spec that way? The stability of the content is a useful feature 
    to have at least.


    
12. Line 779


    Old RegistryEntry label in "Figure 7" should be removed.


    
13. Line 963
    
    
    "... a postal address ..." instead of "... an postal address ..."
    

    
14. Line 997

    "... a Set of PostalAddresses..." instead of "...a Set of PostalAddress..."
    
    
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.
    
    
    
19. Line 1169    "... events ..." instead of "... vents ..."



20. Line 1257    " ... a stored query as .." instead of "... a stored as ..."



21. What is the reason for using QueryExpression as an extensible wrapper.
    Can we just specify two AdhocQuery attributes: queryLanguage and content (query) that will be 
    a String containing the query expression (i.e., SQL query, Filter query, etc.)
    
    
    
22. Line 1342  This line is incomplete" "... conformanceProfile the conformance ..."




23. Line 1467    "... in an approve action..." instead of "... in a approve action..."



23. Line 1478    "... in an undeprecate action..." instead of "... in a undeprecate action..."



24. XACML Related Comment

    Each RegistryObject in the Registry is supposed to have an AccessControlPolicy (ACP). 
    More complex ACPs will put a significant load on almost any operation with 
    large number of objects involved. For example, if you want to update a large number 
    of Associations, a single update operation might require a retrieval of the ACP 
    (through the ACP Association), security checks on source and target referenced objects, 
    security checks on most of the attributes, etc. for both read and update operations. 
    This is just a comment for now. I think that we can hit some performance issues on the 
    Registry and Repository with large number of RegistryObjects and more complex 
    security rules.
    
    
    
25. Line 1573  RegistryAdministrator role is not properly named.



26. Line 1646   "... ebXML Registry" instead of "... ebXML registry..."