- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Thu, 3 Oct 2002 00:27:17 +0600
- To: "Martin Gudgin" <mgudgin@microsoft.com>, <www-ws-desc@w3.org>
"Martin Gudgin" <mgudgin@microsoft.com> writes: > > - We need to have multiple portTypes per service, not just one. We > > believe that different aspects of a service's function are best > > modeled by different portTypes and it does not make sense to > > force one to combine all of them into one portType. > > OK, I've just written up what I think the TF agreed. We need to think > carefully about what we want going forward. I believe the IBM position (as a member of the TF too) has changed. So it is no longer the view of the TF .. sorry. Also, multiple portTypes per service is status quo right? So I'd say the onus is on the proponents of a single portType scenario to justify why its better to go down to one? > > - The service must indicate its "type": with portType inheritance > > in place we (IBM) would prefer to have the service just indicate > > the interfaces it supports: > > <service implements="pt1 .. ptn"> ... </service> > > Are you saying that you don't want port type B to inherit from port type > A but rather that a service would just say that it implements port type > A and port type B? I'm saying that A or B may have their own inheritance hierarchies, but that we do not want to force every service to have precisely one portType. This is functionality that already exists in WSDL .. If one wants to say B inherits from A and then say the service implements B that's fine. However, we believe there are many scenarios where a service will support more than one portType which are not related by an inheritance relationship. > > - The semantics of inheritance needs to be defined more. What are > > the rules for two operations of the same (local) name from two > > inherited portTypes? > > Currently the rule is as defined by: > > 'For each port type operation component in the {operations} property of > a port type component the {name} property must be unique.' > > Which means it would be an error if port type B derived from port type A > and both port types had an operation called 'Foo' > > > I guess the Java (and I assume C# too?) rule > > of ignoring the namespace (package for Java) and just merging > > the local names will work. If there's a conflict then since we now > > don't allow operation overloading, we must require all inherited > > operations of the same name to have the same "signature." Similarly > > if the new portType defines an operation of a same ncname as one > > from an inherited portType, then it must have the same signature > > or its illegal. > > I think I prefer the current formulation. Can't blame you for it, however, it is quite restrictive it seems. However, I'm all for simplicity. Sanjiva.
Received on Wednesday, 2 October 2002 14:29:10 UTC