RE: encodingStyle

Thanks Glen!

i think that resolves all my concerns, in particular over MTOM 
indicators in the schema.

i'm still a little unclear of the actual form the 'metadata' will take 
- that's why i was latching onto 'encodingStyle', but i guess there are 
plenty of other extension mechanisms to provide this info on a per-binding
basis.

FWIW a schema subset which interoperably maps onto 3GLs is something 
i'm constantly asked to provide and seems to form a large part of 
my current day job!
 
Paul

-----Original Message-----
From: Glen Daniels [mailto:gdaniels@sonicsoftware.com]
Sent: 09 January 2004 15:48
To: Downey,PS,Paul,XSJ67A C; www-ws-desc@w3.org
Subject: 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 11:04:37 UTC