Steve Loughran raised the issue of which SOAP version and encoding the OGSA document should recommend or mandate in an 
OGSA-WG message thread "Updated infrastructure writeup, third rev".  The thread finishes with a message from Hiro, to 
which both Dave Snelling and Steve Loughran responded.  Steve's response needs further discussion.

-------------------------------------------

From Dave:
>"The preferred encoding mechanism is document/literal" is OK for me,
>> but mandating is too strict considering current tooling support IMHO.

I agree.

-------------------------------------------

From Steve:
Hiro Kishimoto wrote:

> Hi Steve,
>
> The latest but not the least, our document includes "WS-I profiles."
> The basic profile 1.0 includes SOAP 1.1 and emerging profile 1.1 will include SOAP 1.2 as you mentioned.
>
> SOAP version is important but is it covered by current WS-I profile
> statement?


WS-I 1.1 draft focuses on SOAP1.1, with some forward looking comments about SOAP1.2 and WSDL1.2 (now 2.0, of course). 
The WS-I specs are essentially clarifications as to what is a 'valid' interpretation of the relevant specs if you want 
half-decent interoperability. Presumably a future revision will move to SOAP1.2, as SOAP1.2 becomes more common.

The org sometimes pushes controversial bits, such as WS-I preference of DIME as the attachment mechanism, which is being
 relaxed to DIME or SwA, a relaxation which still ensures that there is no guarantee that JAX-RPC (SwA first) and .NET (
DIME via the WSE package) cannot share files with each other.

The official Axis view on the WS-I specs are "W3C comes first. WS-I comes second. If there is a difference of 
interpretation, the W3C has it". Effectively the group treats the specs as "good citizen", rather than mandatory, and 
not even the next 1.2 release will be tested for compliance (SOAPBuilders gets more of a look in, as do the interop 
workshops).

At the very least, say "SOAP1.1 or later", just to be on the safe side.

>
> "The preferred encoding mechanism is document/literal" is OK for me,
> but mandating is too strict considering current tooling support IMHO.


Which tools are you thinking of? Axis does it. .NET does it. JAX-RPC allows it, even if it is not the default.

Compared to SOAP1.1 vs 1.2, rpc/enc vs doc/lit is much more fundamental. doc/lit is broadly perceived as the better 
marshalling mechanism as it merges with XSD better, and because it more resilent to change. Specifically, you cannot 
effectively handle versioning where the caller sends an older (or even newer) version of a message to the endpoint, 
because all the parameters are anonymous. They are typed, but not named. So you cannot say "ooh, parameter 'processID' 
is missing, we will use the default", all you can say is "we got one less string than expected, but we dont know which 
one".

Which ends up making XML messaging almost a brittle as using XDR or any of the other 'legacy' wire encodings.

I don't deny that a lot of stuff out there uses rpc/enc, the original, but apart from graph serialization, there is no 
compelling reason to use it in new services being written from scratch.

Given that we are trying to define what the best practises for the service communications messages are, with some view 
towards longevity of message stability, I would strongly, strongly, strongly encourage a "you must use doc/lit" 
statement.

Put it this way: is there anyone out there, in this group, coding rpc/enc now except because it is the default of your 
runtime?

If the anwer is yes, and it is because you are encountering interop or others issues with doc/lit implementations, have 
you mailed axis, the appropriate .net team, or whoever else wrote your stack.

-Steve.