RE: proposal for changing binding for WSDL 1.2

Hi Jacek,

It seems your concerns can be summarized as:

1. By abstract the binding data to a separate <bindingType> element, though it's not a problem for "machine" which has good understanding of the "inheritance rule", it's harder for a novice user to get guidance about where this info can be applied. 

2.  Since WSDL hierarchy (sequence of serviceType/portType/operation/input|output|fault) is fixed and quite limited, we can live with just define the bindings under each element, and the benefit of having a modular <bindingType> is not obvious

3. Unless the issue addressed by Sanjiva's proposal can be broken down to several small issues and considered separately, it should be WSDL 2.0 issue

For point 1,  I think we can address it by adding an optional attribute @target which can be used as a hint about where this bindingType should be applied. so the modified grammar may look like below

<bindingType name = "NCname" target = "serviceType|portType|operation|input|output|fault|...">*
 	<!-- binding details -->
</bindingType>
 
<binding>*
   <serviceType name = .. bindingType = "qname"?..>* (depends on the result of the discussion about if binding should be defined in serviceType level) 
     <portType name = .. bindingType = "qname"?..>*
         <operation name = .. bindingType = "qname"?..>*
 	<input name = .. bindingType = "qname"?..>*
	   <parts name= "nmtokens" bindingType = "qname"?...> * 

Also, more generic binding types can be modularly defined if we adopt the suggestions from Jeffrey et al  for Hoisting SOAP Binding Attributes (see http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0058.html). 

For point 2, I view it differently. IMHO, In WSDL1.1, the binding constructs is quite inconsistent with all other constructs. For example, one defines a type then references it in <part>, one defines a <message> then references it in <input|output|fault>.  but when it comes to binding, one has to
mingle the binding data inline with the <binding> element. add <bindingType> will make the wsdl component model more consistent and clean. Just like in a relational database, you can definitely live with putting all data in one table, but separating repetitious data to a separate table will make
reusability much better.   

For point 3.  I believe  <bindingType> can be considered separately from Sanjiva's proposal: the key for the related section of Sanjiva's proposal is about whether we should allow define bindings in the serviceType level. No matter what the WG eventually decided, <bindingType> idea can be applied
with just minor changes. 


Regards,
------------------------------
Canyang Kevin Liu
SAP Labs, Palo Alto
Technology Architecture
3475 Deer Creek Road
Palo Alto, CA 94304
(650) 849-5167
http://www.saplabs.com


> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com]
> Sent: Thursday, September 12, 2002 9:23 AM
> To: Liu, Kevin
> Subject: RE: proposal for changing binding for WSDL 1.2
> 
> 
>  Kevin, 
>  please see my replies below. 8-)
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet Corporation
>                    http://www.systinet.com/
> 
> 
> 
> > >  I'm afraid that while being more modular and more reusable, your
> > > proposal is also more complex to grasp. 
> > 
> > I am not convinced that bindingType proposal is harder to grasp. The
> > key difference between the two proposasls is whether to define 
> > resuable info in a separate module. IMHO, thinking in terms of 
> > relational database, separating resuable data is  just like 
> achiving 
> > first form normalization. I believe
> > the benefits of normalization have been discussed enough 
> 
> I'm not convinced either, that was just my initial reaction. 
> The reason
> why I think it may be harder to grasp is below.
> 
> > >The meaning of specifying
> > > soap:body on wsdl:service/@bindingType is simple - the 
> element will
> > > apply wherever among the descendants of the service where it is
> > > recognized. 
> > >  But there is the IMHO non-obvious expectation that one 
> extensibility
> > > element QName has one global meaning and won't be confused in 
> > > some WSDL
> > > contexts. Even if machine would not be confused, users might.
> > 
> > Maybe I am missing something, but I don't get your point 
> here.  Just 
> > like a input/@message can reference a message/@name, a 
> > service/@bindingType can reference a bindingType/@name. I don't see 
> > anything to do with extensibility Qname. In the grammer below, the 
> > extensible binding details are wrapped
> > inside the <bindingType> element and is referenceable by 
> the bindingType/@name  
> > 
> > <bindingType name = "NCname">*
> >  	<!-- binding details -->
> > </bindingType>
> >  
> > <binding>*
> > 	<serviceType name = .. bindingType = "qname"?..>*
> > 	...
> 
> Let me try to explain using an example:
> 
> First, I'll define a bindingType named 'example':
> 
> <bindingType name="example">
>   <soap:body .../>
> </bindingType>
> 
> Now, the confusion may stem from the fact that the bindingType above
> doesn't say where <soap:body .../> can be used, i.e. where this
> bindingType can be referenced in the portType hierarchy 
> (portTypes with
> operations and input/output/faults).
> 
> So now when I have a binding like
> 
> <binding name="eg2">
>   <serviceType name="st1" bindingType = "example" >
>     <portType name="pt1" />
>     <portType name="pt2" />
>   </serviceType>
> </binding>
> 
> a novice user or a user who doesn't know the <soap:binding> extension
> doesn't get any guidance from the fragment above about what 
> soap:body in
> fact affects - if it's the service, portType, operation or just one
> message in an operation.
> 
> So, back to my previous (quoted) text, by an extensibility 
> element QName
> I meant something like soap:body.
> 
> > 
> > >  Furthermore, WSDL hierarchy is quite simple and not meant to be
> > > extended. Therefore I think Sanjiva's proposal is simpler 
> > > than yours and
> > > suitable for almost as many cases. The rare cases where 
> your proposal
> > > would really bring benefits are not worth the additional 
> conceptual
> > > complexity, IMHO.
> > 
> > Again, I am missing your point:(.  Can you explain what you mean by 
> > wsdl hierachy? I don't see why the bindingType proposal is 
> extending 
> > WSDL hierachy
> 
> by WSDL hierarchy I mean the sequence serviceType/portType/operation/
> input|output|fault. I wasn't saying that your proposal extends this, I
> was saying that because this is fixed and quite limited, your proposal
> doesn't bring as much benefit as it would if the hierarchy was
> extensible or deep.
> 
> > >  Anyway, I think both proposals are very much a 2.0 material, not
> > > necessary for 1.2.
> > 
> > Maybe you are right, but I believe we need to address the 
> problem at 
> > least to some extend in 1.2 given that serviceType is introduced.  
> > Both proposals are just starting points for discussion. We 
> will find 
> > out how much can be done in 1.2.
> 
> Well, at the moment, I don't think much of your or Sanjiva's proposal
> should go to WSDL 1.2. That's mostly because I can't see 
> these proposals
> splitting into smaller pieces that could be applied to the 
> WSD language
> independently. Of course, if you show such a split can be done, then
> each piece can be considered on its own merits.
> 
> I hope I've clarified,
> 
> Jacek
> 
> 
>

Received on Wednesday, 18 September 2002 21:53:30 UTC