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

Re: Describing which blobs are to be optimized.

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
Message-id: <20040614102740.585d397f.alewis@tibco.com>

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?

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.
Received on Monday, 14 June 2004 10:27:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:41 UTC