RE: F&P/MTOM Alternate proposal

Oddly enough, this is a very familiar problem in utilizing WS-Policy
assertions with wsp:optional="true" marker and when the assertions are
not descriptive enough the kind of the pitfalls you may run into. ;-)
 
I am wondering why the WSDL wg is not also considering to define the
MTOM assertion with WS-Policy and define what it means when the message
text/xml is received as part of the defn of the assertion semantics... 
 
Cheers,
 
--umit
 


________________________________

	From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org] On Behalf Of Jonathan Marsh
	Sent: Tuesday, Oct 10, 2006 1:04 PM
	To: 'Arthur Ryman'; 'Youenn Fablet'
	Cc: 'Jean-Jacques Moreau'; www-ws-desc@w3.org
	Subject: RE: F&P/MTOM Alternate proposal
	
	

	I assume {optimizedMimeSeraizliation} = required means the
service will reject any message not XOP-encoded, and will only emit
messages in XOP-encoding.

	 

	But what does "may be engaged" mean?  When I send a message with
text/xml when {optimizedMimeSerialization} = optional, what media type
should I expect to get back?

	 

	Jonathan Marsh  -  http://www.wso2.com <http://www.wso2.com>   -
http://auburnmarshes.spaces.live.com
<http://auburnmarshes.spaces.live.com> 

	 

	
________________________________


	From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org] On Behalf Of Arthur Ryman
	Sent: Tuesday, October 10, 2006 11:02 AM
	To: Youenn Fablet
	Cc: Jean-Jacques Moreau; www-ws-desc@w3.org;
www-ws-desc-request@w3.org
	Subject: Re: F&P/MTOM Alternate proposal

	 

	
	Youenn, 
	
	Looks good. 
	
	Arthur Ryman,
	IBM Software Group, Rational Division
	
	blog: http://ryman.eclipsedevelopersjournal.com/
	phone: +1-905-413-3077, TL 969-3077
	assistant: +1-905-413-2411, TL 969-2411
	fax: +1-905-413-4920, TL 969-4920
	mobile: +1-416-939-5063, text: 4169395063@fido.ca 
	
	

Youenn Fablet <youenn.fablet@crf.canon.fr> 
Sent by: www-ws-desc-request@w3.org 

10/10/2006 05:50 AM 

To

www-ws-desc@w3.org 

cc

Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr> 

Subject

F&P/MTOM Alternate proposal

 

 

 

	
	
	
	
	Per my action item, here is an alternative proposal for MTOM
support 
	within WSDL2.0.
	This is a translation of the current MTOM support through an
extension 
	element.
	Regards,
	   Youenn
	-----------------------------
	The proposal is the following:
	
	Add a new WSDL2.0/MTOM extension within section 5 (soap binding)
of the 
	WSDL20 adjunct specification, along the following lines.
	
	//// WSDL Component Relationship /////
	The WSDL2.0/MTOM extension adds the following property to the
WSDL2.0 
	Endpoint, Binding, Binding Operation, Binding Fault, Binding
Message 
	Reference and Binding Fault Reference components:
	  - {optimizedMimeSerialization} OPTIONAL. Its type is xs:token.
When 
	present and equal to "required",  it indicates that MTOM  must
be 
	engaged. When present and equal to "optional", it indicates that
MTOM 
	may be engaged. When not present, no assertion is made about the
use of 
	MTOM.
	
	The requiredness/availability of the MTOM engagement is defined
by the 
	closest present property, where closeness is defined by whether
it is at 
	the Endpoint component level, the Binding Message Reference
component or 
	Binding Fault Reference component level, the Binding Operation
level, 
	the Binding Fault Reference level, or the Binding component
level, 
	respectively.
	
	
	//// XML Representation ////
	The XML representation for the WSDL2.0/MTOM  extension is an
element 
	information item as follow:
	  <wsmtom:OptimizedMimeSerialization wsdl:required="true|false"?
	
	
xmlns:wsmtom="http://www.w3.org/2004/08/soap/features/http-optimization"
/>
	This is an empty global element that allows any namespaced
attribute 
	(especially the wsdl:required attribute).
	
	//// Mapping ////
	The {optimizedMimeSerialization} property is present when a 
	wsmtom:OptimizedMimeSerialization element is present.
	Its value is "required" if the wsdl:required attribute is
present and 
	equals to "true". Otherwise its value is "optional".
	-----------------------------
	
	
	

Received on Tuesday, 10 October 2006 20:33:13 UTC