[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 25: proposal
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 --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]