Re: Describing which blobs are to be optimized.

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 Wednesday, 14 July 2004 18:02:57 UTC