Re: [regrep-comresolve] Re: [regrep-comment] RIM 2.0 Comments/Questions

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Agreed with the minor comment. The relationship was obvious enough that the
reviewer figured it out on their own
and suggetsed the replacement. So yes the relationship is quite obvious.

"Munter, Joel D" wrote:

> Thanks for your efforts Farrukh.  This is a very good first pass.
>
> On your proposed resolution for the (new) Issue #175, please consider
> removing the word "minor."  This adjective may have the propensity to
> trivialize the reviewer's comment. On that same issue resolution, is it
> obvious that the type for getOrganizations is somehow related to the
> attributeType of an Association?
>
> Joel
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> Sent: Monday, April 08, 2002 9:44 AM
> To: 'Oasis RR Comment Resolution'
> Subject: [regrep-comresolve] Re: [regrep-comment] RIM 2.0
> Comments/Questions
>
> Team,
>
> Please review my proposed response to this email and send email. I would
> like to post a response soon.
> Thanks.
>
> Goran Zugic wrote:
>
> > 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.
>
> The ServiceBinding schema element is always composed within a parent
> Service element. Likewise the
> SpecificationLink schema element is always composed within a
> ServiceBinding element. Consequently
> they do not need (nor have) a reference to their parent object. This is
> deliberate and not a mistake.
>
> > 2) Section 9.6.2 on page 40:
> > "...
> > 9.6.2 Confirmation of Extramural AssociationsExtramural 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)
>
> The cloned Association is the same Object as the original and therefor
> has the same id. There is one Association
> object with one UUID that is globally unique but has two clones. This is
> deliberate and not a mistake.
>
> > getOrganizations(String type) method in RegistryObject should be
> > changed to getOrganizations(LongName type).  4) Section 10.3.5 on page
> > 50:
>
> This is a minor error that we will fix in a future version of RIM We
> have logged in our issues list as:
>
> Issue 175: getOrganizations(String type) method in RegistryObject should
> be changed to getOrganizations(LongName type).
>
> Resolution: This minor error will be fixed in a future version of RIM.
> The information however is available to the reader by looking at the
> data type for the associationType attribute of class Association.
>
> >
> > "...
> > 10.3.5 Attribute nodeRepresentationIf 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
>
> For example consider the taxonomy is NAICS and the value is Book
> Publishers. In this case the
> nodeRepresentation is "51113" which is the NAICS code for "Book
> Publishers".
>
> > Classification getPath() and getCode() methods?
>
> getPath method may be used like an attribute in queries. See example in
> RS 2.0 at:
>
> 8.3.7.4 Getting Objects Classified By a ClassificationNode line 3455.
>
> The getCode method may be used like an attribute in Classification
> queries where the taxonomy value is needed
> without caring whether it is an internal Classification or an external
> Classification.
>
> You could have a query like:
>
> SELECT * from Classification where code LIKE "&Book%"
>
> > 5) Could you please explain how an owner of a registry object can be
> > determined from the RIM v2.0 security model?
>
> The owner of a RegistryObject can be determined by looking at the first
> AuditableEvent in the Audit trail
> for the RegistryObject and using its user attribute.
>
> > 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.
>
> v2.0 is not backward compatible with v1.0. We have firm plans for
> maintaining backward compatibility between
> v2.0 and v3.0.
>
> > Regards,
> > Duka Krunic & Goran Zugic
> > Members of ebXMLsoft Development Team
> > www.ebxmlsoft.com
>
> --
> Regards,
> Farrukh
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Regards,
Farrukh