RE: encodingStyle

Hi Paul:

> 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/.

That's what we were discussing yesterday - this is, I believe, not yet
the case, although it may be if someone steps up to the plate to define
the schema subset which maps "neatly" to 3GLs.

> 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.

That's correct, there will be some metadata, usually in the binding,
which will determine the serializiation on the wire.

> 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 ?

I believe we were discussing the idea of baking media-type metadata into
the schema (which is squarely in the sights of our media-type taskforce
as well as MTOM) - this would simply indicate to anyone who happens to
care that a given XML element has a particular media-type.  A
non-MTOM-aware processor could still deal with XML matching that schema
by reading/writing base64binary data inline, whereas an MTOM processor
could more efficiently serialize the same data by encoding it as a
binary MIME part.  So the serialization itself is still up to the
processor/binding, but the metadata needed to perform that serialization
in an efficient way is available to anyone using the data types.

--Glen

Received on Friday, 9 January 2004 10:49:31 UTC