RE: encodingStyle


thanks, that does help a lot, i'll try and rephrase my concern:

In WSDL 1.1. use='encoded' indicated two separate things: 

 - a restriction on the schema in the WSDL (no attributes, etc)
 - graph encoding (possible replacement of an element with id/idref)

AIUI the first will be covered in 2.0 by operationStyle=~/RPC/.

It is the second feature i'm puzzled by: what in WSDL 2.0 indicates how 
the infoset is encoded/decoded on the wire. I'd imagined that a binding 
specific 'encodingStyle' would identify which serialiser to employ:  
XML text, XML binary, MTOM, ASN1, section5 or whatever.

I gathered on the call that MTOM would have a flag in the schema, which
in my mind precludes different serialisations being used in different 
bindings for the same message ?


-----Original Message-----
From: Glen Daniels []
Sent: 08 January 2004 18:01
To: Downey,PS,Paul,XSJ67A C;
Subject: RE: encodingStyle

Hi Paul! 

> As I now understand it, in WSDL 2.0 the schema employed to 
> describe the data being exchanged will also describe the 
> actual serialisation of the data 'on the wire'.

This is not in fact the case.  The schema describes the infoset which
will be "rehydrated" at the receiving end, no matter the serialization.
Depending on where we end up going with things like soap:header, that
might not even exactly be true either (though I hope it remains so).

> Doesn't this remove the ability for the same infoset to be 
> exchanged using different serialisations:  XML text, MTOM, or 
> whatever and necessitate a new schema /language/ just to 
> support a different message encoding ? 

I don't believe so, no.

> It seems to me that there was real benefit in encodingStyle: 
> multiple bindings could easily present the same data but 
> exchanged over different transports *and* serialisations.

The benefit to encodingStyle was that you could rely on the schema
looking a particular way (elements, no attributes, etc) and that you
could know that any given element's content might be replaced with an
href="" attribute.


Received on Friday, 9 January 2004 05:14:40 UTC