- From: Amelia A Lewis <alewis@tibco.com>
- Date: Mon, 14 Jun 2004 10:27:40 -0400
- To: David Booth <dbooth@w3.org>
- Cc: www-ws-desc@w3.org
An excellent description of the semantic of optionality in our from-the-point-of-view-of-the-service world. Perhaps this clarification could be incorporated somewhere? Amy! On Fri, 11 Jun 2004 17:50:16 -0400 David Booth <dbooth@w3.org> wrote: > > Regarding the discussion about the meaning of an optional feature, I > think this issue is actually already addressed on our draft, and I think > the draft has it right, though it's possible we should add more > clarification. > > Section 8.3 > http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#processor > says "A conformant WSDL processor MAY safely ignore a NON-mandatory > extension that it does not recognize or that it does not choose to > implement." (and also clarifies that the conformant processor is acting > on behalf of the requester entity -- not the provider entity). > > This means that if a WSD declares a feature to be optional (i.e., it > declares the feature but does not set wsdl:required=true), then a > provider agent implementing that WSD MUST NOT send a message that > requires the requester agent to support that feature, UNLESS the > provider agent has some other information -- beyond what is stated in > the WSD -- that assures the provider agent that the requester agent > actually supports that feature. For example, in a request-response > interaction, the requester agent might provide such information by > sending a message that includes a flag indicating "by the way, I support > feature X, so you may use that feature when you send back your > response". > > This is NOT a symmetric interpretation of "optional", for a very good > reason: The WSD identifies (and applies to) the particular provider > agent identified by the endpoint declaration. But it does not identify > the requester agent. It applies to *any* hypothetical requester agent > that engages the provider agent under this WSD. The WSD permits the > provider agent to declare its own support for a feature (which any > requester agent may therefore use), but there is no way in the WSD to > declare what any particular requester agent ACTUALLY supports. It is > only possible to declare a requirement of what the (hypothetical) > requester MUST support. > > >From: Hugo Haas <hugo@w3.org> > >Date: Mon, 7 Jun 2004 16:15:55 +0200 > >. . . > >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 > >. . . . > > Careful. As explained above, unless the provider agent has other > information to know that the requester agent actually supports the > feature, then the provider agent should not send the requester agent a > message that requires use of the feature. > > >From: Glen Daniels <gdaniels@sonicsoftware.com> > >Date: Mon, 7 Jun 2004 11:49:19 -0400 > > > >. . . Second, we could add something like a "mustUnderstand" attribute > >to feature/module declarations, which indicates that anyone using the > >WSDL must understand the given extension, but that the usage of that > >extension is still optional unless "required='true'" is specified. . . > >. > > It sounds like you're suggesting a way to distinguish between requiring > the requester agent *accept* messages that use a particular feature, > versus requiring the requester agent to *send* messages using a > particular feature. > > I don't think we need to add anything to WSDL to gain this ability, > since it could be done by splitting feature X into two features, X-input > and X-output --- one pertaining to service input and the other to > service output: > feature X-input means that feature X is used on service input > feature X-output means that feature X is used on service output > > So on combining these two features with the two possible values of > wsdl:required, we get four cases: > > 1. Declaring feature X-input with wsdl:required=false means that the > requester agent MAY send messages using feature X, and the provider > agent will understand them. > > 2. Declaring feature X-input with wsdl:required=true means that the > requester agent MUST send messages using feature X, and the provider > agent will understand them. > > 3. Declaring feature X-output with wsdl:required=false means that the > provider agent has the ABILITY to send messages using, but should not do > so without other information to know that the requester agent can accept > them. > > 4. Declaring feature X-output with wsdl:required=true means that the > provider agent MUST be prepared to receive messages using feature X. > > > > -- > David Booth > W3C Fellow / Hewlett-Packard > Telephone: +1.617.253.1273 > -- Amelia A. Lewis Senior Architect TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Monday, 14 June 2004 10:27:52 UTC