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