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] | [List Home]


Subject: Re: [regrep] RIM 3.0 Comments


Thanks very much for the comments Goran. Please see responses inline below.

Goran Zugic wrote:

> 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.
>  
>
+1. Fixed.

>2. Table of Contents
>
>   Line 187    "6.2.3 Attribute accessURI" duplicated
>  
>
+1. Fixed.

>     
>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   
>  
>
The reason for this was that it makes an extra level which in some cases 
reaches 5 levels.
Suggest to leave unchanged but will consider if others feel the same as 
you.

>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.
>  
>
Interesting point. Lets discuss today in con call. I am open to the idea.

>5. New Classes such as Registry, Federation, Subscription etc., are not added to the 
>   "Figure1: Information Model Relationships View" (Page 13, Line 407)
>  
>
The figure is not meant to show all classes but only key classes related 
to RegistryObject. It would be too cluttered to show all IMO.
Lets discuss today in con call.

>   
>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.
>  
>
Section 1.6 in introduction describes this already. I can consider 
describing the word canonical in terminology section if others feel its 
warranted.

>  
>7. Line 563    It should be "... versionInfo attribute ..." instead of "... objectType attribute ...".
>  
>
+1. Fixed.

>8. Line 569	2.6.1 Attribute Summary
>
>   RegistryObject id is needed to support a relationship between a VersionInfo and RegistryObject.
>  
>
The infomodel is not meant to describe the XML Schema and the id 
attribute and its role in linkage is left unspecified.
If people feel it should be specified then I can consider it.

>      
>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.
>  
>
Since they had some special meaning and required some special 
description I thought it made sense to redefine it here.
I propose we keep it that way.

>   
>10. Line 614   2.8.1 Attribute Summary
>
>    RegistryObject id is needed to support a relationship between a Slot and RegistryObject.
>  
>
Same as comment (8)

>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.
>  
>
userVersion is now being handled by the comment attribute of VersionInfo
Stability and Expiration are completely removed. In my experience no one had
used these features so I thought it would be better to leave as an impl 
specific feature
rather than standardizing. If others feel strongly we can add canonical 
slots and normative
behavior description. Lets discuss in meeting.

>    
>12. Line 779
>
>
>    Old RegistryEntry label in "Figure 7" should be removed.
>  
>
+1. Fixed.

>    
>13. Line 963
>    
>    
>    "... a postal address ..." instead of "... an postal address ..."
>  
>
+1. Fixed.

>        
>14. Line 997
>
>    "... a Set of PostalAddresses..." instead of "...a Set of PostalAddress..."
>  
>
+1. replaced with

"...a Set of PostalAddress instances..."

>        
>15. Line 1031    5.5.1 Attribute Summary
>
>    RegistryObject (User, Organization) id is needed to support a relationship between a 
>    PostalAddress and RegistryObject.
>  
>
Same as comment (8)

>    
>    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.
>  
>
There is a problem here that PostalAddress is not an Identifiable so has 
no id. Maybe we need to make it so or remove Slots on this class.

>16. Line 1054   5.6.1 Attribute Summary
>
>    RegistryObject (User, Organization) id is needed to support a relationship between a 
>    TelephoneNumber and RegistryObject.
>  
>
Same as comment (8)

>17. Line 1074   5.7.1 Attribute Summary
>
>    RegistryObject (User, Organization) id is needed to support a relationship between an 
>    EmailAddress and RegistryObject.
>  
>
Same as comment (8)

>    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.   
>  
>
There is a problem here that EmailAddress is not an Identifiable so has 
no id. Maybe we need to make it so or remove Slots on this class.

>18. Line 1086    5.8.1 Attribute Summary
>
>    RegistryObject (User) id is needed to support a relationship between a 
>    PersonName and RegistryObject.
>  
>
Same as comment (8)

>    
>    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.
>  
>
There is a problem here that PersonName is not an Identifiable so has no 
id. Maybe we need to make it so or remove Slots on this class.

>    
>19. Line 1169    "... events ..." instead of "... vents ..."
>  
>
+1. Fixed.

>20. Line 1257    " ... a stored query as .." instead of "... a stored as ..."
>  
>
+1. Fixed.

>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.)
>  
>
The query expression could be structured XML as in filtered query and 
XQuery. I think this was a major improvement on query extensibility as 
proposed by Richard and I feel we should keep it intact.

>        
>22. Line 1342  This line is incomplete" "... conformanceProfile the conformance ..."
>  
>
+1. Replaced with "... conformanceProfile that declares the conformance 
..."

>23. Line 1467    "... in an approve action..." instead of "... in a approve action..."
>  
>
+1. Fixed.

>23. Line 1478    "... in an undeprecate action..." instead of "... in a undeprecate action..."
>  
>
+1. Fixed.

>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.
>  
>
Lets discuss this in con call.

>25. Line 1573  RegistryAdministrator role is not properly named.
>  
>
+1. Fixed.

>26. Line 1646   "... ebXML Registry" instead of "... ebXML registry..."
>  
>
+1. Fixed globally.

-- 
Regards,
Farrukh



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