RE: HTML version of operation name proposal

> -----Original Message-----
> From: Roberto Chinnici [mailto:roberto.chinnici@sun.com] 
> Sent: 31 January 2003 19:29
> To: Sanjiva Weerawarana
> Cc: Martin Gudgin; www-ws-desc@w3.org
> Subject: Re: HTML version of operation name proposal

<SNIP disposition='stuff that is not germane to the point I want to
make' />

> 
> > Yes, WSDL bindings are more complex with overloading. However, its 
> > only more complex for the person with overloaded stuff. With this 
> > proposal, every operation needs to be referred to by QName; thereby 
> > affecting ALL users.
> >
> > Here's an example binding for {nsuri-3}pt3 (see my original post):
> >
> > <definitions targetNamespace="nsuri-3" xmlns:tns="nsuri-3" 
> xmlns:y="nsuri-1"
> >              xmlns="wsdl namespace">
> >   <portType name="pt3" extends="y:pt1">
> >     <operation name="o1"> .. </operation>
> >   </portType>
> >
> >   <binding name="b1" type="x:pt3" xmlns:x="nsuri-3">
> >     <!-- anything common to all operations is fine and it 
> goes here -->
> >     <operation name="y:o1"> .. stuff for inherited o1 .. 
> </operation>
> >     <operation name="y:o2"> .. stuff for inherited o2 .. 
> </operation>
> >     <operation name="x:o3"> .. stuff for my operation o1 .. 
> </operation>
> >   </binding>
> >
> > Notice that operation names in binding/operation/@name now end up 
> > being QNames. (Yes yes we can use two attributes namespace + name 
> > instead but you still need to specify the namespace.)
> 
> Yes, but how is that hard? We already use QNames to refer to 
> things in so many places, there's nothing new to learn.
> 

I would note that at the component model level, there are always as many
binding operation components as there are port type operation components
in the specified port type, regardless of what the serialized XML looks
like. This needs to be the case otherwise our attribute roll-up decision
won't work.

I would also note that it would only be necessary to specify the
namespace name in the serialization where the local name was ambiguous.
So, if I were suggesting syntactic changes I'd say let the current
syntax stand for the non-ambigous cases and add an optional namespace
attribute for use when there is ambiguity.

Gudge

Received on Friday, 31 January 2003 15:10:02 UTC