MTOM Properties

At the ERCIM face-to-face I took an action item to write up a list of
properties we might find a use for in MTOM. Below is such a write-up.
Please do not read anything into this mail regarding my personal opinion
on whether any, all or none of these properties are actually needed.
Also please note that names are just made up for now, we can decide what
actual names to use if/when we decide to adopt any of these. Feel free
to suggest additional properties I've missed.

Gudge



Global Properties


Sender side:

We currently have a single property on the sender side of a message
exchange:

http://www.w3.org/2003/06/soap/features/abstract-optimization/Optimizati
onCandidates 

which is 

 "A list containing zero or more (pointers to) element information items

  within the SOAP envelope [which are] candidates for being transmitted 
  in an optimized way."

[] is text added by me.

Other sender side properties we might consider are:


http://www.w3.org/2003/06/soap/features/abstract-optimization/ElementsRe
quiringOptimization

which would be 

 "A list containing zero or more (pointers to) element information items

  within the SOAP envelope which MUST be transmitted in an optimized
way."

This gives control over which EIIs MUST be optimized, while allowing
implementations to optimize additional EIIs as they see fit. Downside is
that whoever populates this property ( probably the 'application' )
might not know the characteristics of the underlying binding and hence
might mandate 'optimization' of EIIs that it actually doesn't make sense
to optimize.


http://www.w3.org/2003/06/soap/features/abstract-optimization/ElementsTh
atMustNotBeOptimized

which would be 

 "A list containing zero or more (pointers to) element information items

  within the SOAP envelope which MUST NOT be transmitted in an optimized
way."

This gives control over which EIIs MUST NOT be optimized, while allowing
implementations to optimize additional EIIs as they see fit. Downside is
that whoever populates this property ( probably the 'application' )
might not know the characteristics of the underlying binding and hence
might mandate 'optimization' of EIIs that it actually doesn't make sense
to optimize.


Receiver Side Properties

We might also consider a receiver side property:

http://www.w3.org/2003/06/soap/features/abstract-optimization/OptimizedE
lements

which would be 

 "A list containing zero or more (pointers to) element information items
  within the SOAP envelope which were transmitted in an optimized
fashion"

Whether this list is exhaustive or a hint is something we would need to
decide. Is an implementation required to faithfully fill in this
property? Or can it leave it empty? I can see reasons to for either
approach.

We *might* also want to propogate the sender side 

http://www.w3.org/2003/06/soap/features/abstract-optimization/ElementsRe
quiringOptimization

and

http://www.w3.org/2003/06/soap/features/abstract-optimization/ElementsTh
atMustNotBeOptimized

properties over to the receiver.


Other global properties

http://www.w3.org/2003/06/soap/features/abstract-optimization/Optimizati
onType

Which would be 

 "A QName indicating the optimization mechanism to be used"

currently only xsd:base64Binary is defined. Note we might also need
finer grained control over this, see below. This property makes sense on
both the sender and receiver sides of the exchange.


Other properties

The above are all properties that broadly apply to MTOM as an
optimization mechanism. We might also want to define properties that
apply to specific optimized pieces:


http://www.w3.org/2003/06/soap/features/abstract-optimization/EII/Optimi
zationType

Which would be:

 "A QName indicating the optimization method used for a given element 
  information item"

This is similar to the global property above, but at the EII level.
Something like this might be needed if we decide to allow optimization
of types other than base64.


http://www.w3.org/2003/06/soap/features/abstract-optimization/EII/Conten
tType

Which would be:

 "An RFCXXXX media-type specifying a media type for the content of
element 
  information item"

This information mimics at the property level what is currently present
in the SOAP envelope as xmime:MediaType attribute and present in the
multipart packaging as a Content-Type header in PASWA.

Received on Tuesday, 2 September 2003 11:05:31 UTC