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