Issue 25 inlined proposal v4

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

Attached.
I accepted changes from v3, so the change marks shown are only for 
changes between v3 and v4.

The 1st change is on lines 116-118, which states what must happen if 
<endpointReference> is not supported. The wording is slightly different 
from what I had proposed in the chat. I refer to the SCA WS Binding XML 
document definition from section 5.1 instead of just saying any document 
(which is what I had proposed in the chat).

The 2nd change is on lines 183-188. This states that the SOAP 1.1 intent 
must be specified either in mayProvides or alwaysProvides and SOAP 1.2 
intent should be specified in mayProvides.

Dave, SimonN and I had an impromptu call after the TC call to discuss 
the 2nd change so as to shorten the turnaround time, as this is a little 
tricky. Here is the gist/conclusion of that call:

1) Section 4.1 makes it very clear that SOAP 1.1 and SOAP 1.2 intents 
are mutually exclusive. Currently the policy spec does not make it so 
and Dave is going to raise an issue regarding.

2) We can't mandate that SOAP 1.1 be in the alwaysProvides (since that 
rules out SOAP 1.2 support), but we can't disallow it either (for 
specialized runtimes).

3) SOAP 1.2 can never be in the alwaysProvides (as this would rule out 
any SOAP 1.1 support).

4) The only possible choices (wrt these two intents) are:
a) alwaysProvides="SOAP.1_1" and mayProvides=""
b) alwaysProvides="SOAP.1_1" and mayProvides="SOAP.1_2"
c) alwaysProvides="" and mayProvides="SOAP.1_1"
d) alwaysProvides="" and mayProvides="SOAP.1_1 SOAP.1_2"

5) mayProvides means that if you specify the intent in the SCDL then you 
get a biding/policy that implements it without having to provide any 
other config info. For the SOAP 1.1 intent this is currently always true 
given that empty <binding.ws> element (with no other intent) 
automatically gives you SOAP 1.1 without providing any specific config 
info. IOW, not having SOAP 1.1 intent in either mayProvides or 
alwaysProvides doesn't make a lot of sense.

6) Having SOAP.1_2 in the mayProvides serves a useful purpose, it allows 
someone to not worry about SOAP 1.2 config info and just use the 
<binding.ws> in conjunction with the 1.2 intent and be done.

Comments?

-Anish
--

sca-binding-ws-1.1-spec-cd02_issue25-proposal-v4.doc

sca-binding-ws-1.1-spec-cd02_issue25-proposal-v4.pdf