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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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