Re: Describing which blobs are to be optimized.

Anish,

The out-in MEP does involve the requester agent sending a message, so an 
optional feature could be relevant for that MEP.

In the case of the out-only MEP, I think your conclusion is largely 
correct.  However, I'm not sure I would go as far as to say that an 
optional feature would NEVER make sense for an out-only MEP, because it's 
hard to imagine what all possible features might be.  Even for out-only, 
there usually is some protocol handshaking that requires the requester 
agent to do something when it receives a message, so it's conceivable that 
the handshake could involve the use or non-use of such an optional feature.

As an example of using ".. some other information -- beyond what is stated 
in WSD ..." to know that the requester agent supports a particular optional 
feature, the requester agent might send a message to the provider agent 
indicating "Henceforth you can send your out-only messages to me using 
optional feature X".  After that point, the provider agent would know to 
use the feature when sending out-only messages to the requester agent.


At 02:55 PM 7/23/2004 -0700, Anish Karmarkar wrote:
>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.

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Monday, 26 July 2004 14:45:12 UTC