Re: Describing which blobs are to be optimized.

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

The requester agent sends a message _after_ the message is sent by the 
provider agent. So, in this respect I am not sure how this is different 
than out-only 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.
> 

Makes sense. Thx.

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

Received on Tuesday, 27 July 2004 04:24:21 UTC