Issue 25: proposal

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

I went through our ML archives for discussion on 25 (if you are 
interested it happened in 5/8, 6/8 and 7/8. We also had a discussion on 
this during one of our f2f (but I did not get a chance to look at the 
minutes for that f2f). The discussions are about a lot of things 
including whether the binding should be renamed to binding.soap, have 
multiple bindings (for those who attended the f2f, may remember the 
matrix) etc.

In the spec what we have is:
1) binding.ws that is wsdl 1.1 based, but extensible
2) soap 1.1/http defaults for <binding.ws/>

Given that the raison d'�tre for binding.ws is soap using WSDL 1.1 as 
the description language, I would like to suggest the following 
direction for the resolution:

1) An implementation that claims conformance to this spec MUST support 
the bare <binding.ws/> element (i.e. support soap 1.1/http)
{corollary: Any implementation that claims conformance to this spec MUST 
include "soap.1_1" intent in its list of mayProvides}

2) An implementation that claims conformance to this spec SHOULD support 
  the use of @wsdlElement within <binding.ws> element.

3) An implementation that claims conformance to this specification and 
supports the use of @wsdlElement within <binding.ws> element MUST 
support the WSDL 1.1 binding for SOAP 1.1 and SOAP 1.2.

With the two above, I'm trying to balance few things:
needs of portability or providing more teeth to conformance, the 
possibility that someone may want to support soap 1.1/http but doesn't 
want to support WSDL 1.1, and the need to avoid creation of profile(s) 
that would make <binding.ws> more meaning.

Comments?

-Anish
--