Updated WSDL generation - a.k.a. web service binding defaults

As per my assigned task for the binding TC, the following is my set of
proposed changes to deal with WSDL generation for binding.ws.

I apologize for not having this ready in advance of today's call. 
Looks like I was off by about six hours.

Relative to WD 02, changes to section 4 include:

  
Changed section 4 name

  
Changed the introduction to the section

  
Minor edits to section 4.1

  
Section 4.2 removed, with the exception of the suggested target
namespace which has moved to Appendix B.

  
Section 4.3 --> 4.2, WSDL Bindings --> Default Binding. 
Rewrote section.

  
Section 4.3.1 --> 4.2.1  => removed text about WSDL
generation.

  
Section 4.4 --> 4.3 => clarified that interface.XXX must be
converted to either a WSDL 1.1 portType or a WSDL 2.0 interface (is
this redundant?)

  

  
Migrated salient details from Section 4.5 about WSDL generation
to Appendix B, which merely suggests choices for various elements of a
generated WSDL.

  

-Eric.

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
ought 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

In the event that the transport details are not
determined elsewhere, the following configuration SHOULD be used:

  

    
HTTP-based transport

  

  

    
Use SOAP 1.1

  

  

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

  

  

    
For messages that have a single part, the
message uses “document” style, as per section 3.5 of [WSDL11].

  

  

    
For messages that have multiple parts, the
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.

    

  

  

    
For SOAP 1.1 messages, the SOAPAction 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 body of the
message

  

4.2.1 SOAP versions

Where no specific version of SOAP has been
dictated, an SCA runtime might support both version 1.1 and version
1.2.

4.3
WSDL portType or interface

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

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, policy
implementation decisions can affect the way WSDL might be generated.
For reference, and possible consistency, this section picks options
for various details involved in generating WSDL.

  

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

  

  

    
import each
portType or interface, 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”