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

Fwd: Re: Describing which blobs are to be optimized.

From: David Booth <dbooth@w3.org>
Date: Fri, 11 Jun 2004 17:54:06 -0400
Message-Id: <5.1.0.14.2.20040611175252.032a84f8@localhost>
To: www-ws-desc@w3.org
Cc: Hugo Haas <hugo@w3.org>, Glen Daniels <gdaniels@sonicsoftware.com>, Ugo Corda <UCorda@SeeBeyond.com>, xml-dist-app@w3.org

[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
Received on Friday, 11 June 2004 17:54:10 GMT

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