Restating proposal for issue 11

Since Anish and I exchanged a number of emails on this:

http://lists.oasis-open.org/archives/sca-bindings/200809/msg00052.html

http://lists.oasis-open.org/archives/sca-bindings/200809/msg00053.html

http://lists.oasis-open.org/archives/sca-bindings/200809/msg00054.html

http://lists.oasis-open.org/archives/sca-bindings/200809/msg00055.html

http://lists.oasis-open.org/archives/sca-bindings/200809/msg00056.html

http://lists.oasis-open.org/archives/sca-bindings/200809/msg00072.html

http://lists.oasis-open.org/archives/sca-bindings/200810/msg00009.html

http://lists.oasis-open.org/archives/sca-bindings/200810/msg00010.html

http://lists.oasis-open.org/archives/sca-bindings/200810/msg00011.html

http://lists.oasis-open.org/archives/sca-bindings/200810/msg00012.html

... I figured I should go back through and come up with a precise
proposal, so that we could resolve this at the virtual F2F.

I incorporated all of Anish's text from the email of
http://lists.oasis-open.org/archives/sca-bindings/200809/msg00052.html,
and then tried to incorporate the results of our email thread.

So here's the text - a complete replacement for section #4 of the
existing text, plus a new Appendix B, inserted before the existing
Appendix B (Acknowledgments).

4 Transport Binding

The binding.ws element provides numerous ways to
specify exactly how messages ought to be transmitted from or to the
reference or service. Those ways include references to WSDL binding
elements from the @wsdlElement attribute, policy intents, and even
vendor extensions within the binding.ws element. However, all of
those ways to indicate how messages get carried happen to be
optional. This section describes the defaults that MUST be used if the
specific transport
details are not otherwise specified.

4.1 Intents

So as to narrow the range of choices for how messages
are carried, the following policy intents affect the transport
binding.

  

    
soap

This indicates that messages MUST be transmitted using SOAP. One or
more SOAP versions can be used.

  

  

    
soap.1_1

Messages MUST be transmitted using only SOAP 1.1.

  

  

    
soap.1_2

Messages MUST be transmitted using only SOAP 1.2.

  

4.2 Default Binding
4.2.1 WS-I Basic Profile Alignment
To align to WS-I Basic Profile, the resulting WSDL port must be all
document-literal, or all rpc-literal binding (R2705). 
This means, for any given portType, for all messages referenced by all
operations in that portType, either

  
that every message part references an XML Schema type
(rpc-literal pattern)

    

  
or that every message references exactly zero or one XML
Schema elements (document-literal pattern)

A portType that does not fit one of these two patterns MUST be
treated as an error by a conforming implementation.  The rest of this
section assumes the short-hand reference of a "rpc-literal" or
"document-literal" pattern, depending on which of the two bullet points
above it matches.

4.2.2 Default Binding Rules

In the event that the transport details are not otherwise
determined, a conforming implementation MUST enable the following
configuration:

  

    
HTTP-based transfer protocol

  

  

    
Except when an intent or policy mandates the use of only SOAP
1.2, support SOAP 1.1

  

  

    
“literal” format as described in section 3.5 of [WSDL11]

  

  

    
For messages that have a single part, thedocument-lteral
pattern, each message uses “document” style, as per section 3.5 of
[WSDL11].

  

  

    
For messages that have multiple parts, therpc-literal
pattern, each message uses “rpc” style, as per section 3.5 of
[WSDL11]. In this case, the child elements of the SOAP Body element
must be namespace qualified with a non-empty namespace name. This
namespace MUST be the URI associated with component, with a
"service-name/binding-name" appended.

  

  

    
For SOAP 1.1 messages, the SOAPAction HTTP header described in
section 6.1.1 represents the empty string, in quotes (“”).

  

  

    
For SOAP 1.2 messages, the optional SOAP Action feature
described in section 6.5 of [SOAP12Adjuncts] does not appear.

  

  

    
All message parts are carried in the SOAP body

  

4.2.13 SOAP versions

Where no specific version of SOAP has been dictated, an SCA
runtime MUST
generate bindings for SOAP
1.1.

4.3
WSDL portType

An SCA service has a single interface description. For the Web
Services binding, this interface description MUST be converted into
a WSDL
1.1 portType.

B. Appendix - WSDL Generation

Due to the number of factors that determine how a WSDL might be
generated, including compatibility with existing WSDL uses, precise
details cannot be specified. For example, implementation decisions can
affect the way WSDL
might be generated. For reference, and consistency, this section
suggests non-normative choices for some of the various details
involved in generating WSDL.

  

    
wsdl:definitions/@name =
<componentName> + "." + <serviceName>

  

  

    
wsdl:definitions/@targetNamespace =
<HTTP Base URI> + ”/” + <componentName> + “/” +
<serviceName>

  

  

    
import each WSDL 1.1 portType,
rather than putting them inline

  

  

    
wsdl:binding/@name = <name of binding> + <SOAP
Version> + “Binding”

  

  

    
wsdl:service/@name = <name of the
service>

  

  

    
wsdl:port/@name = <name of binding> + <SOAP Version>
+ “Port”

  

In the above, "<SOAP Version>" should be either
"SOAP11" or "SOAP12" as appropriate.