Re: [sca-bindings] Re: Restating proposal for issue 11

[Eric Johnson <eric@tibco.com>]

Comments on Mike's comments (with a little trimming to take out things you don't need to read again):

Mike Edwards wrote:

OF8761B854.02F3450C-ON80257515.003F3869-80257515.0045D6E0@uk.ibm.com" type="cite">
Folks,

Comments inline as <mje>...</mje>

The following comes in two parts - moving the gist of what is the existing section 4.4, which is the original text that turned into (the now deleted) section 4.3 below, and the revision for the rest of section 4.  First, the normative statement about mapping to WSDL:

---

Section 2.2, paragraph #1 currently reads:
When binding.ws is used on a service or reference with an interface that is not defined by interface.wsdl, then a WSDL portType for the service or reference is derived from the interface by the rules defined for that SCA interface type.

I suggest changing this to:
When binding.ws is used on a service or reference with an interface that is not defined by interface.wsdl, then a WSDL portType for the service or reference is derived from the interface by the rules defined for that SCA interface type.  A conformant SCA runtime MUST raise an error if the interface does not map to a WSDL portType.

<mje>I suggest using the term "An SCA runtime MUST" rather than "A conformant SCA runtime MUST" - the question of conformance should be left to be dealt with elsewhere</mje>

Agreed.

OF8761B854.02F3450C-ON80257515.003F3869-80257515.0045D6E0@uk.ibm.com" type="cite">And finally, here's the replacement for section four, including all the edits we discussed today.

---

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 MUSTto 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 Transport Binding Rules
4.2.1 WS-I Basic Profile Alignment
To align to WS-I Basic Profile, the resulting WSDL port mustneeds to 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. 
<mje>A portType which comes from where??  I think some explanation of what entities are being processed is necessary here - if this is simply the portType from the <interface/> (directly or derived by mapping) then say so.
</mje>
<mje>There is that "conforming implementation" term again - "SCA runtime" is the agreed term</mje>

I think we agreed in the call that this would be:

"For a service element, the portType from the service's interface or derived from the service's interface MUST fit one of these two patterns."

OF8761B854.02F3450C-ON80257515.003F3869-80257515.0045D6E0@uk.ibm.com" type="cite">
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 Transport 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, supportgenerate bindings for SOAP 1.1 <mje>I'd rewrite this as follows:  Bindings for SOAP 1.1 are used, except where an intent or a policy is applied which mandates the use of SOAP 1.2 in which case Bindings for SOAP 1.2 are used.</mje>

One point here, which I agree with, is that Mike wants to start with the assertion, not the exception.  Another point here is that Mike wants this to read something like "Bindings for only SOAP 1.1 are used, ..."  That is, the default is to generate SOAP 1.1 bindings and nothing else, unless policy says to generate SOAP 1.2 bindings, and nothing else.

My take is that is a gratuitous over-specification, and violates the notion of being lenient in what one accepts, and rigorous in what one produces (the obvious counterpoint to this would be things that pose a security risk - SQL injection anyone? - but I don't think this is one of those cases).  I like the notion that an implementation is free to generate bindings for both SOAP 1.1 & SOAP 1.2 as a default, on the same endpoint, if the implementation thinks it useful.

So my restatement: "Bindings for SOAP 1.1 are provided, and bindings for SOAP 1.2 can be provided, unless policy is applied that explicitly restricts this choice to one or the other."

OF8761B854.02F3450C-ON80257515.003F3869-80257515.0045D6E0@uk.ibm.com" type="cite">

• "literal" format as described in section 3.5 of [WSDL11]
• For document-lteralliteral pattern, each message uses "document" style, as per section 3.5 of [WSDL11].
• For rpc-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 mustMUST be namespace qualified with a non-empty namespace name. This namespace MUST be the structural URI associated with component, with a "service-name/binding-name" appended the binding. <mje>Why this namespace?</mje>

Why not?  Seriously, though, the options seem to be:

1. Specify nothing (remove this last sentence - the previous sentence that it must be namespace qualified still stands)
   
2. Specify constraints, but not specific detail, as in, "each binding MUST use a different namespace"
3. Specify an alternate specific choice
4. Use the current specific choice.
   

I can live with any of the options from 2 - 4.  I don't think #1 is a good idea.  It was Anish's idea to suggest the current option (#4).  Option #4 has the benefit of being closely tied to the binding itself, and satisfies the only possible rule I can think of that would make up #2.

-Eric.