RE: should binding/operation/infault|outfault@messageReference be opt ional?

Oh I see the motivation.

But in the case that interface/operation/infault|outfault@messageReference is not present and the processor fails to infer a value from the pattern (following the rules specified in draft)and so the value of @messageReference is "empty",  what value should be specified for the required binding/operation/infault|outfault@messageReference? 

Best Regards,
Kevin
 

-----Original Message-----
From: Jeffrey Schlimmer [mailto:jeffsch@windows.microsoft.com] 
Sent: Tuesday, Nov 11, 2003 05:13 PM
To: Liu, Kevin; www-ws-desc@w3.org
Subject: RE: should binding/operation/infault|outfault@messageReference be opt ional?



Kevin, I'm guilty of that inconsistency. :-) I held off making a
comparable change to the binding components because I want to make sure
we (really I) understand how the @name and @messageReference attributes
work first. 

For instance, is binding//@name sufficient to disambiguate which
interface sub-component is being modified? Or does binding//* need to
point back to the message (fault) references defined in the message
exchange pattern?

--Jeff 

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Liu, Kevin
> Sent: Monday, November 10, 2003 11:35 AM
> To: www-ws-desc@w3.org
> Subject: should binding/operation/infault|outfault@messageReference be
opt
> ional?
> 
> 
> In the current draft, the attribute
> interface/operation/infault|outfault@messageReference is optional, the
> following rules are provided for determining its value:
> 
> "The actual value of the messageReference attribute information item
if
> any; otherwise the {message reference} property of the message with
the
> same {direction} from the {message exchange pattern} of the Interface
> Operation component, provided there is exactly one such message and
the
> fault pattern of the {message exchange pattern} is
fault-replaces-message;
> otherwise the {message reference} property of the message with the
> opposite {direction}, provided there is exactly one such message and
the
> fault pattern is message-triggers-fault; otherwise empty. "
> 
> However, the binding/operation/infault|outfault@messageReference is
> required, and leave the two sections somehow not consistent. The
syntax
> for fault references is something like,
> 
> <definitions>
>   <interface>
>     <operation>
>       <infault
>             name="xs:NCName"
>             messageReference="xs:NCName"?
>             message="xs:QName"?
>         <documentation />?
>       </infault>*
>       <outfault
>             name="xs:NCName"
>             messageReference="xs:NCName"?
>             message="xs:QName"?
>         <documentation />?
>       </outfault>*
>     </operation>
>   </interface>
> 
> <binding>
>     <operation>
>       <infault
>             name="xs:NCName"
>             messageReference="xs:NCName" >
>         <documentation />?
>       </infault>
>       <outfault
>             name="xs:NCName"
>             messageReference="xs:NCName" >
>         <documentation />?
>       </outfault>
>     </operation>
>   </binding>
> 
> </definitions>
> 
> I believe the intention of making messageReference in interface level
> optional is to make simple case very simple whereas the intention of
> requiring messageReference in binding fault is to use the combination
of
> @name and @messageReference to uniquely identify a corresponding
interface
> fault. But to be consistent, I would say we should either make the
> interface/operation/infault|outfault@messageReference required OR make
> binding/operation/infault|outfault@messageReference optional and
specify
> the rules for determining its value. I would prefer the later to keep
> simple cases simple (for wsdl authors).
> 
> Make senses?
> 
> Best Regards,
> Kevin
>

Received on Wednesday, 12 November 2003 20:51:53 UTC