RE: Describing which blobs are to be optimized.

Prasad,
You are assuming that the WSDL was defined by the server provider. 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.
> 
> 
>

Received on Friday, 4 June 2004 20:34:35 UTC