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

binding/operation/{infault, outfault} allows specifying fault-specific
binding details. To unambiguously refer to a particular fault declared
in interface/operation, interface/operation/{infault, outfault} has a
required name attribute; the value of this attribute must be specified
in the name attribute on binding/operation/{infault, outfault}. 

Do I have that right?

interface/operation/{infault, outfault}/@messageReference does not
identify a fault; it associates a fault with a specific message (per the
Message Triggers Fault or Fault Replaces Message fault rule).

Is there any reason at all for the messageReference attribute on
binding/operation/{infault, outfault}? It appears to be strictly
redundant with the corresponding interface/operation/{infault,
outfault}/@messageReference.

--Jeff

> -----Original Message-----
> From: Liu, Kevin [mailto:kevin.liu@sap.com]
> Sent: Wednesday, November 12, 2003 5:52 PM
> To: Jeffrey Schlimmer; www-ws-desc@w3.org
> Subject: 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, 19 November 2003 19:38:38 UTC