W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2004

Re: Proposal: collapse binding namespaces

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Thu, 20 May 2004 20:24:16 +0600
Message-ID: <007e01c43e76$21a040b0$ddc24a09@LANKABOOK>
To: <paul.downey@bt.com>, <www-ws-desc@w3.org>

I am not comfortable with this approach.

> Template Driven Syntax
> ----------------------
> WSDL provides a syntax framework for each binding to extend in its own
> binding specific namespace. Each binding has to populate the common
> component model, so it made sense for WSDL to provide the common XML
> to achieve this. e.g. the SOAP 1.2 binding[1] :

The value of this template approach is that we (WSDL authors) can define
a common framework for every binding. While that may feel like a burden,
the main value of it is that that allows us to define rules like what we
for binding/operation/(input|output)/@messageLabel defaulting.

> Processing the binding at the XML level could be simplified by
> putting the whole binding in a single binding specific namespace:
>  <binding name="xs:NCName" interface="xs:QName"? >
>     <documentation />?
>     <binding protocol="xs:anyURI"
>                    mepDefault="xs:anyURI"?
>                    webMethodDefault="xs:string"?
>           xmlns="http://www.w3.org/2003/11/wsdl/soap12">

You have a nested binding element from another namespace. IMO that's
ugly and unncessary.

>     <module uri="xs:anyURI" required="xs:boolean"? >
>       <property ... />?
>     </module>*
>     <header element="xs:QName" />*
>     <feature ... />*
>     <property ... />*
>     <fault wsoap:ref="xs:QName"
>       code="xs:QName"
>       subcodes="list of xs:QName" />
>       <documentation />?
>     </fault>*
>     <operation ref="xs:QName" >
>       <documentation />?
>       <operation mep="xs:anyURI"?
>                        webMethod="xs:string"?
>                        action="xs:anyURI"? />?
>       <input messageLabel="xs:NCName"? >

Note that whether @mssageLabel can be optional or not depends on the
WSDL mep that's used by the parent operation element. Your approach would
require *every* binding author to re-define those rules. IMO that sucks.

> A processor no longer has to 'channel surf' between namespaces
> when when populating the component model.

I doubt that switching namespaces is a hard thing to do. The value of a
consistent semantic is much more IMO.

> FreeForm Binding Syntax
> -----------------------
> Having taken the step to move each binding into its own namespace,
> here is a further quite radical step we could take:
>   Given a processor has to understand a binding namespace to be able
>   to use it and each binding implements the complete interface,
>   why make the syntax for each binding uniform at all?

Hmm. That's precisely what you've done above .. all the binding elements
are in another namespace so there's no WSDL part1 rules on what
those elements look like.

> The publisher of a binding would be at liberty to decide on any
> syntax that best describes his protocol rather than being constrained
> by a WSDL binding template. All should be well so long as the author
> of a binding specification clearly described how to move the infoset
> to and from the WSDL binding component model.
>  <binding name="xs:NCName" interface="xs:QName"? >
>     <documentation />?
>     <soapBinding  xmlns="http://www.w3.org/2003/11/wsdl/soap12">
>         ... cool SOAP specific syntax
>    </soapBinding>
>     <rayGunBinding  xmlns="http://www.w3.org/2003/11/wsdl/soap12">
>         ... cool lawn cutting specific syntax ...
>    </rayGunBinding>
>  </binding>

You could make this more interesting by saying let's drop wsdl:binding
totally and just say let each binding define their bindings and have the
endpoint refer to it by QName. That can work too (and will  be even more
freeform than what you suggest) but then again every binding author would
have to define their own rules for dealing with WSDL MEPs and defaulting
stuff etc. I don't think that's a good thing but YMMV.

> This has obvious advantages for bindings where the notion of an operation
> or fault is either very obvious or meaningless. It may simplify our spec
> and resolve a lot of our binding issues by making them more solvable on
> a per-biding basis.
> Consider the HTTP binding which comes with four default methods. Why
> force this binding to describe these methods, or talk in terms of
> operations at all, just to satisfy the 'WSDL binding template'?

You don't need to ... you have to use the WSDL binding template only
if necessary. That is, if you don't need to say anything on a per-operation
basis then you don't need to use any of the template pieces at all.

Received on Thursday, 20 May 2004 10:24:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:40 UTC