W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

Re: Describing which blobs are to be optimized.

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Fri, 23 Jul 2004 14:55:35 -0700
Message-ID: <41018957.9040909@oracle.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT