doc/lit and WS-I

[Russell Butek <bu...@us.ibm.com>]

WS-I is forming it's base profile as I write this note.  They are
suggesting that all web services engines MUST support, at a minimum,
doc/lit over the wire.  This means that we must be able to export doc/lit
WSDL, ie., provide a doc/lit flag on Java2WSDL.  What sort of WSDL do we
export?  The same we do now except replacing rpc/encoding with
document/literal?  Or a .NET style (which the WS-I folks are viewing as a
SOAP section 7 style - though I don't completely agree - I think Microsoft
did things that shouldn't have been done - like essentially ignoring the
message clause)?  Just adding a flag on Java2WSDL doesn't go far enough.
For instance, how will the runtime distinguish overloaded operations for an
incoming doc/lit SOAP message?  There are no xsi types in the message to
give us hints.  I'm sure there are other issues:  arrays?  multiref?

In essence, there is NO spec that maps WSDL doc/lit to a SOAP message
(you'd think the WSDL spec would have provided a mapping, but it doesn't).
Most of the items are fairly straightforward and most folks have made the
same guesses.  But without a spec, there are some issues, like overloaded
operations, for which there is a good possibility for everyone to come up
with a different solution.

So what do WE do?  See what others have done and try to toe the same line?
Come up with our own 'spec' and implementation and hope others follow?

Could someone who knows .NET tell us how they solve the overloaded
operations problem?

Russell Butek
butek@us.ibm.com

Re: doc/lit and WS-I

[Simon Fell <so...@zaks.demon.co.uk>]

On Wed, 22 May 2002 10:21:43 -0700, in soap you wrote:

>
>----- Original Message -----
>From: "Russell Butek" <bu...@us.ibm.com>
>To: <ax...@xml.apache.org>
>Sent: Wednesday, May 22, 2002 5:57 AM
>Subject: doc/lit and WS-I
>
>
>> WS-I is forming it's base profile as I write this note.  They are
>> suggesting that all web services engines MUST support, at a minimum,
>> doc/lit over the wire.  This means that we must be able to export doc/lit
>> WSDL, ie., provide a doc/lit flag on Java2WSDL.  What sort of WSDL do we
>> export?  The same we do now except replacing rpc/encoding with
>> document/literal?  Or a .NET style (which the WS-I folks are viewing as a
>> SOAP section 7 style - though I don't completely agree - I think Microsoft
>> did things that shouldn't have been done - like essentially ignoring the
>> message clause)?
>
>Here is my fundamental issue with the WS-I: is it focused on interop, like
>SOAP builders, or public rubberstamping of existing implementations to meet
>the implementors strategic goals.
>
>I mean, its not like the MS implementations pay full attention to section 5,
>and the .net stack(s) dont do SwA _or_ their proposed DIME alternative.

Yup, sounds to me like its rubber stamping. If they're mandating
doc/literal, is that full XSD support, or a subset of XSD, and if a
subset, is it documented ?

Cheers
Simon

Re: doc/lit and WS-I

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Russell Butek" <bu...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Wednesday, May 22, 2002 5:57 AM
Subject: doc/lit and WS-I


> WS-I is forming it's base profile as I write this note.  They are
> suggesting that all web services engines MUST support, at a minimum,
> doc/lit over the wire.  This means that we must be able to export doc/lit
> WSDL, ie., provide a doc/lit flag on Java2WSDL.  What sort of WSDL do we
> export?  The same we do now except replacing rpc/encoding with
> document/literal?  Or a .NET style (which the WS-I folks are viewing as a
> SOAP section 7 style - though I don't completely agree - I think Microsoft
> did things that shouldn't have been done - like essentially ignoring the
> message clause)?

Here is my fundamental issue with the WS-I: is it focused on interop, like
SOAP builders, or public rubberstamping of existing implementations to meet
the implementors strategic goals.

I mean, its not like the MS implementations pay full attention to section 5,
and the .net stack(s) dont do SwA _or_ their proposed DIME alternative.