RE: Port type extension proposal

> -----Original Message-----
> From: Steve Tuecke [mailto:tuecke@mcs.anl.gov]
> Sent: 03 October 2002 06:49
> To: Sanjiva Weerawarana
> Cc: Martin Gudgin; www-ws-desc@w3.org
> Subject: Re: Port type extension proposal
> 
<SNIP/>
> > > > - 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'
> 
> That is not what this member of the TC thought he agreed to. :-)
> 
> We have a perfectly good disambiguator between the two
> operations that have 
> an name of 'Foo', namely the qname of the portType in which 
> the operation 
> is declared.  So the fully qualified names of the operations 
> are basically 
> A:Foo and B:Foo.

The problem is that the disambiguator[sic] is not ( currently ) visible
at the binding level. The current formulation at least works with the
current binding mechanism. Off the top of my head I can see a couple of
ways forward:

1. Make operation names QNames, by promoting operation to be top level
components of a description. Bindings would then reference operation
names by QName rather than a name which is local to a port type.
Syntactically we can do this one of two ways:

	a. Make operations top-level syntactic constructs and have port
types reference them
	b. Say that operation names are qualified by the targetNamespace
even through they are nested inside port types.

2. Modify bindings so that they also support inheritance, bind each port
type in turn, and end up with an aggregate binding for all the port
types up the inheritance hierarchy. This would probably look something
like Kevin's proposal for reusable binding components. Operation names
would stay as local names.

3. Modify bindings so that operations are referred to by combination of
port type name and operation name. Operation names would stay as local
names.

I'm sure there are other approaches we could take. I present these as
possible ways forward, I'm sure people will come up with other
suggestions.

> 
> To push on this a bit more...  What if you have a portType A
> with operation 
> 'Foo', a portType B with operation 'Foo', and portType C that 
> extends both 
> A and B?  Would this also be an error?  If so, I think you 
> are completely 
> breaking encapsulation.  The designers of portTypes A and B 
> cannot choose 
> their operations in isolation.  In effect, this decision would force 
> designers to ensure that all operation ncnames be globally 
> unique (without 
> the benefit of namespaces) if you hope to allow them to be 
> aggregated by 
> independent parties. This effectively negates most of the 
> purpose of having 
> portType extension, which is to allow reasonable modelling of 
> interfaces 
> and interface extension.

Another interesting question ( to me, at least ), which is along the
same lines, is what happens if two operations in a port type reference
the same global element declaration ( via a message ). How does a
service disambiguate them? It seems like this is a similar problem.
portType designers apparently need to make sure they don't use the same
GEDs for messages, otherwise there is no way to tell them apart on the
wire. 

Gudge

Received on Thursday, 3 October 2002 10:55:53 UTC