RE: Describing which blobs are to be optimized.

Hi Prasad,
I am not sure what you mean by "WSDL still represents a contract from
the service perspective". In my view, WSDL represents a mutual contract
that equally binds both the client and the server. 
 
If we are talking about who really desires the MTOM feature, that should
be whoever wrote the WSDL and introduced the request for that feature.
And, as I mentioned before, that could either be the client or the
server provider.
 
Regards,
Ugo

	-----Original Message-----
	From: Prasad Yendluri [mailto:pyendluri@webmethods.com] 
	Sent: Friday, June 04, 2004 7:45 PM
	To: Ugo Corda
	Cc: Marc Hadley; Jonathan Marsh; www-ws-desc@w3.org;
xml-dist-app@w3.org
	Subject: Re: Describing which blobs are to be optimized.
	
	
	Hi Ugo,
	
	Ugo Corda wrote:
	

		Prasad,
		You are assuming that the WSDL was defined by the server
provider. 

	No, I was not assuming that. Even if the service (and hence the
WSDL) was defined to meet the requirements of a client, 
	the WSDL still represents a contract from the service
perspective. If it was defined to meet the client requirement, we have 
	the best case scenario; the client and server have the same
understanding (for a change ;)
	

		That
		should not necessarily be the case. The typical use case
is the one
		where the user of the service dictates the WSDL details
to the server
		provider (e.g. Walmart asking one of its partner to
provide a service
		that satisfies a WSDL interface as specified by
Walmart). In that case,
		the optimization requirements come from the user, not
the provider.
		
		Ugo
		
		  

			-----Original Message-----
			From: www-ws-desc-request@w3.org 
			[mailto:www-ws-desc-request@w3.org] On Behalf Of
Prasad Yendluri
			Sent: Friday, June 04, 2004 5:27 PM
			To: Marc Hadley
			Cc: Jonathan Marsh; www-ws-desc@w3.org;
xml-dist-app@w3.org
			Subject: Re: Describing which blobs are to be
optimized.
			
			
			
			Since it is the server that is marking this
optional, my 
			interpretation 
			would be that the server prefers to send and
receive optimized 
			serializations but the client is not required
oblige it. If 
			the client 
			does not initiate with an optimized
serialization then the 
			server SHOULD 
			not use the optimization. I agree the semantics
of "optional" 
			nature of 
			this feature need to be captured properly.
			
			Regards, Prasad
			
			Marc Hadley wrote:
			
			    

				On a related note I'm unclear on the
semantics implied by 
				      

			marking the
			    

				MTOM/XOP feature as optional. I can see
several interpretations:
				
				(i) a service will never use it but a
client may
				(ii) a service will not use it unless
client does first
				(iii) a service will always use it but a
client isn't obliged to
				
				Marc.
				
				On Jun 4, 2004, at 2:27 PM, Jonathan
Marsh wrote:
				
				      

				The WS Description WG is working through
an issue (#207 
				        

			[1]), which 
			    

				is XOP-related.  As we communicated to
you earlier [2], 
				        

			the ability 
			    

				of a service to accept and transmit XOP
can be indicated by 
				indicating the HTTP Transmission
Optimization Feature is in use 
				through the WSDL feature syntax.  This
syntax also allows the MTOM 
				feature to be "required", which we
interpret as, the 
				        

			service must be 
			    

				sent a XOP envelope and media type,
though XOP itself doesn't 
				constrain which parts of the XML within
that envelope have been 
				optimized (it could be none).
				
				A question arises ([3] continuing on
[4]) that if XOP is required, 
				whether it further makes sense to say
precisely which parts of the 
				message are to be optimized.  As we
understand it, this allows a 
				service to place additional restrictions
on the use of XOP beyond 
				what the XOP spec describes, but not
leaving it completely 
				        

			up to the 
			    

				application layer.  These additional
restrictions could be 
				        

			along the 
			    

				lines of "anything marked with an
expectedMediaType 
				        

			attribute must be 
			    

				optimized", to a fine level of
granularity through an 
				xop:optimize="true" attribute on the
schema.
				
				The working group has a preference
(straw poll 7 to 4 [5]) to 
				indicate in some fashion which parts
must be optimized.  However, 
				since you own the HTTP Transmission
Optimization Feature, 
				        

			we wanted 
			    

				to ask you two
				questions:
				
				1) Do you feel that such descriptive
hints would be useful 
				        

			or is it 
			    

				contrary to the expected usage patterns
of XOP?
				2) If it is useful, would you be willing
to describe these hints, 
				including introducing syntax, in the
MTOM or XOP specs?  
				        

			(Splitting a 
			    

				feature and it's descriptive hints
across multiple specs seems 
				suboptimal to us.)
				
				[1]
http://www.w3.org/2002/ws/desc/2/06/issues.html#x207
				[2] 
				        

	
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0077.html
			    

				[3] 
				        

	
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0089.html
			    

				[4] 
				        

	
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0000.html
			    

				[5] 
				        

	
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0019.html
			    

				---
				Marc Hadley <marc.hadley at sun.com>
				Web Products, Technologies and
Standards, Sun Microsystems.