- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Fri, 23 Jul 2004 14:55:35 -0700
- To: David Booth <dbooth@w3.org>
- Cc: Marc Hadley <Marc.Hadley@Sun.COM>, www-ws-desc@w3.org, Glen Daniels <gdaniels@sonicsoftware.com>, Hugo Haas <hugo@w3.org>, Ugo Corda <UCorda@SeeBeyond.com>, xml-dist-app@w3.org, David Fallside <fallside@us.ibm.com>
Does that mean that an optional feature does not make sense in the case of out-only and out-in MEPs? OR does ".. some other information -- beyond what is stated in WSD ..." include proprietary/undefined ways to finding such information? Thx. -Anish -- David Booth wrote: > > Marc, > > The WSD WG accepted[1] my proposed clarification[2], although as of this > writing the editors have not yet incorporated this clarification into > Section 8.3 of our draft document[3]. > > In essence, the clarification was: > [[ > 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". > ]] > > Let me know if you have further questions about this. > > > References > 1. WG accepted proposed clarifications: > http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0192.html > 2. Proposed clarifications: > http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0090.html > 3. WSDL 2.0 Editor's draft: > http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#processor > > > > At 06:06 PM 7/14/2004 -0400, Marc Hadley wrote: > >> I took an action on this weeks XMLP telcon to enquire as to the >> resolution of the issue raised about the meaning of >> wsdl:required="false" on the proposed feature. Was this resolved and if >> so how ? >> >> Thanks, >> Marc. >> >> On Jun 11, 2004, at 5:54 PM, David Booth wrote: >> >>> >>> [Reposting because I forgot to copy xml-dist-app@w3.org. Sorry!] >>> >>> 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 >>> >> --- >> Marc Hadley <marc.hadley at sun.com> >> Web Products, Technologies and Standards, Sun Microsystems. > >
Received on Friday, 23 July 2004 17:56:26 UTC