[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep] ROWS vote
Thanks for the detailed technical comments on the proposal, Len. I was all along hoping to see more of such comments and you have certainly helped maintain my hope :-) About the issues ... 1, 2) The understanding I had was that inclusion of any new object types in the RIM should be via child relationship with RegistryObject and RegistryEntry is meant for extrinsic object support. However, with a closer look, now I find that the RegistryEntry children are really metadata types and instances of these will not exist independently i.e. instances of AuditableEvent, Classification, Association, etc will always be coexisting with a RegistryEntry object representing the real registry entry. The User and Organization however are still types that can be instantiated on their own, but again they are not much useful without association with a RegistryEntry instance. If this is the case i.e. RegistryObject children are to be limited to metadata types alone, I agree with you that the Service and ServiceBinding should be associated with RegistryEntry. 3) You are right that the SpecificationLink has characteristics of Association, as by definition it is a "link". However, SpecificationLink are heavy weight objects in my proposal, that contain runtime parameters controlling the particular usage of the Specification by the Service. i.e. associationType attribute of Association class alone is not sufficient to capture the link between a Specification and the ServiceBinding. 4) Good catch, the "targetBinding" certainly requires further definition. Initially, I had left it there for handling cases of redirection of Services, etc. However, I am ready to take it out as it is not completely spelled out in the current proposal. 5) The Service and ServiceBinding special association type is labeled as "bindings" in the diagram in lines 70 - 71. The ServiceBinding to to SpecificationLink association certainly needs a special type. Will do. Len, please let me know what you think about the changes outlined above, mainly whether these changes would incline you towards approving the proposal. thanks, Sanjay Patil ---------------------------------------------------------------------------- ------------------------------ IONA Total Business Integration (TM) Phone: 408 350 9619 http://www.iona.com -----Original Message----- From: Len Gallagher [mailto:LGallagher@nist.gov] Sent: Monday, October 22, 2001 11:33 AM To: Lisa Carnahan Cc: regrep@lists.oasis-open.org Subject: Re: [regrep] ROWS vote Regrep TC, I vote to "Disapprove" the ROWS proposal for the following technical reasons: 1) The proposal hints that the proposed new Service class should be treated as metadata like a RegistryEntry instance, yet it defines it as a sub-class of RegistryObject - why? It seems more natural to me to treat it as a special sub-class of RegistryEntry that provides metadata for some "service" repository item. 2) The proposal hints that the proposed new ServiceBinding class should be treated as metadata like a RegistryEntry instance, yet it defines it as a sub-class of RegistryObject - why? It seems more natural to me to treat it as a special sub-class of RegistryEntry that provides metadata for some "service binding" repository item. 3) In lines 96-100, the proposal says that a SpecificationLink instance provides the linkage between a ServiceBinding and one of its "technical specifications", which could be a WSDL document or a CORBA IDL document. If such "technical specifications" are important, shouldn't they also be registered in the Registry and have RegistryEntry instances that describe them? If so, shouldn't the "link" be treated as an Association instance in the model, linking the registered ServiceBinding to the registered WSDL or CORBA IDL document? 4) The diagram in lines 70-71 pictures a "targetBinding" relationship from the ServiceBinding class to itself. However, there is no attribute or method defined for this class to explain what it means. The proposal should either define what "targetBinding" means or delete the relationship from the diagram. 5) The diagram in lines 70-71 defines generic Associations between RegistryObjects as well as "special" associations between Service and ServiceBinding and between ServiceBinding and SpecificationLink. Since all three of these new classes are sub-classes of RegistryObject, why aren't the "special" associations defined as "special" subtypes of the more generic Association. Shouldn't the proposal define a "special" ebRIM "AssociationType" to use for this purpose? I'm prepared to change my vote to "Approve" if these technical issues can be resolved in a way that is consistent with the intended usage of existing ebRIM facilities. NOTE: I'm not convinced by the other negative ballots on this proposal that seem to say that our committee shouldn't define a Registry specification capable of registering all types of business services. I think it's perfectly natural that some Registry implementations will want to register business services and associated service bindings and link them to WSDL or CORBA IDL declarations. They may even want to treat these registered objects in a special way. But they'll do it by registering those objects in a normal way, i.e. with a RegistryEntry description, and by linking those registered objects in the normal way, i.e. with Association instances that have specialized "associationType" attributes. Then they'll define special methods as shortcuts on these classes if that is appropriate. -- Len At 08:20 AM 10/18/01, Lisa Carnahan wrote: >To OASIS/ebXML Registry TC Voting Members, > >This is a ballot on the ROWS Proposal attached to the archived message >referenced below. Please note that this Proposal is a revision to the >initial version that was sent to the TC. > >Please indicate your vote as Approve, Disapprove or Abstain to the >Proposal. Please indicate your vote to me by sending me email directly to >lisa.carnahan@nist.gov. (You may send your vote to the TC list; however >you are certainly not required to do so.) Please send your response by >Tuesday, October 22. > >The ROWS Proposal can be found at: >http://lists.oasis-open.org/archives/regrep/200110/msg00023.html > >I'm still out of the office, if you wish to discuss this vote, please >contact me on Monday. > >--thanks >-lisa --------------InterScan_NT_MIME_Boundary-- ************************************************************** Len Gallagher LGallagher@nist.gov NIST Work: 301-975-3251 Bldg 820 Room 562 Home: 301-424-1928 Gaithersburg, MD 20899-8970 USA Fax: 301-948-6213 ************************************************************** ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC