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



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
**************************************************************



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


Powered by eList eXpress LLC