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