[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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC