W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

Re: Describing which blobs are to be optimized.

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Mon, 07 Jun 2004 10:54:51 -0400
To: Hugo Haas <hugo@w3.org>
Cc: Jonathan Marsh <jmarsh@microsoft.com>, www-ws-desc@w3.org, xml-dist-app@w3.org
Message-id: <A0E77EE0-B892-11D8-B006-000A95BC8D92@Sun.COM>

On Jun 7, 2004, at 10:15 AM, Hugo Haas wrote:
>
> * Marc Hadley <Marc.Hadley@Sun.COM> [2004-06-04 16:03-0400]
>> 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
>
> Section 2.7.1[1] specifies:
>
> | The presence of a feature component in a WSDL description indicates
> | that the service supports the feature and may require a requester
> | agent that interacts with the service to use that feature.
>
> When the use of the MTOM feature is not required, it just means that
> the service supports it, which means that the requester agent or the
> provider agent may use it, depending on the direction of the message
>
> Your interpretations can be described with:
>
> (i) the input message description has an optional MTOM feature
> component associated with it, and the output message doesn't.
>
> (iii) the input message description has an optional MTOM feature
> component associated with it, and the output message has a required
> MTOM feature component associated with it.
>
> If an optional MTOM feature were specified on an operation, both the
> requester and provider agent may use it.
>
> I don't believe that (ii) is describable with WSDL 2.0. It goes into
> the domain of policies, I think.
>
Is it permissible to associate an optional MTOM feature with an output 
message ? If so, I can see two interpretations:

(a) A requestor must be able to support the MTOM feature since the 
service may use it (i.e. for a requestor the feature is mandatory to 
support but it may not be used).
(b) The service uses some out of band information to decide whether or 
not to use the feature (i.e. for a requestor the feature is optional to 
both support and use).

Interpretation (a) doesn't seem to be covered by [1]. Interpretation 
(b) pretty much falls back to interpretation (a) for implementation 
purposes unless the out-of-band information is clarified (if a 
requestor doesn't know how a service is going to decide whether or not 
to use the feature then it will have to be prepared to support it).

Marc.

>
>   1. http://www.w3.org/TR/2004/WD-wsdl20-20040326/#Feature_details

---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.
Received on Monday, 7 June 2004 10:59:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT