OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-comment message

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


Subject: [regrep-comment] RIM 2.0 Comments/Questions


We hope that you don't mind if we just add few comments/questions belonging to the OASIS/ebXML Registry Information Model (RIM) v2.0 specification. We already implemented RIM v1.0 specification and currently we are finishing an implementation of the RIM v2.0 specification.  We would like to share with you some of the issues regarding the v2.0 specification:
 
1) ServiceBinding and SpecificationLink are missing Service and ServiceBinding references, respectively. In our current implementation we added a Service reference 
   (service) to the ServiceBinding class and a ServiceBinding reference (serviceBinding) to the SpecificationLink class. 
 
 
2) Section 9.6.2 on page 40:
"...
9.6.2 Confirmation of Extramural Associations
 
Extramural associations may be thought of as a unilateral assertion that may not be viewed as truth until it has been confirmed by the other (extramural) parties
involved (Users "u2" and "u3" in the example in section 9.5). To confirm an extramural association, each of the extramural parties (parties that own the source or target object but do not own the Association) must submit an identical Association (clone Association) as the Association they are intending to confirm using a SubmitObjectsRequest. The clone Association must have the same id as the original Association.
..."
 
The clone Association cannot have the same id as the original Association because the id is a Universally Unique ID (UUID).
 
 
3) getOrganizations(String type) method in RegistryObject should be changed to getOrganizations(LongName type).
 
 
4) Section 10.3.5 on page 50:
"...
10.3.5 Attribute nodeRepresentation
 
If the Classification instance represents an external classification, then the nodeRepresentation attribute is required. It is a representation of a taxonomy
element from a classification scheme. It is the responsibility of the registry to distinguish between different types of nodeRepresentation, like between the
classification scheme node code and the classification scheme node canonical path. This allows client to transparently use different syntaxes for nodeRepresentation.
..."
 
Could you please give an example of the nodeRepresentation attribute value that is "a representation of a taxonomy element from a classification scheme."?
Could you also please give an example of the external Classification getPath() and getCode() methods?
 
 
5) Could you please explain how an owner of a registry object can be determined from the RIM v2.0 security model?
 
 
6) We believe that v2.0 had to be backward compatible with V1.0. We hope that you will take care of the backward compatibility issue in the future specification versions/releases.
 
Regards,
Duka Krunic & Goran Zugic
Members of ebXMLsoft Development Team
www.ebxmlsoft.com
 
 


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


Powered by eList eXpress LLC