RE: Adding binding infault/outfault components (LC55)

Thank you, yes, my questions were answered on the call.

Asir

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Sanjiva Weerawarana
Sent: Friday, November 19, 2004 2:48 PM
To: Asir Vedamuthu; 'Roberto Chinnici'; www-ws-desc@w3.org
Subject: Re: Adding binding infault/outfault components (LC55)



Hi Asir,

IIRC we rejected your item (2) below: the faults have to be *bound*
only once per interface. However, we wanted to allow people
to specific SOAP modules, features and properties for faults
on a per-operation basis.

Sanjiva.

----- Original Message ----- 
From: "Asir Vedamuthu" <asirv@webmethods.com>
To: "'Roberto Chinnici'" <Roberto.Chinnici@Sun.COM>; <www-ws-desc@w3.org>
Sent: Thursday, November 18, 2004 9:27 PM
Subject: RE: Adding binding infault/outfault components (LC55)


>
> I read your proposal and have two questions,
>
> [1] it appears to me that binding fault reference and binding message
> reference look alike to some extent. However, their component structures
are
> very different. And, their mappings from xml infoset are different too.
Why
> are these different? BTW, I like your proposed component structure. Would
> you recommend upgrading binding message reference component structure to
>
> {message reference} REQUIRED - A Message Reference component
> {features} OPTIONAL - A set of Feature components
> {properties} OPTIONAL - A set of Property components
>
> [2] in light of your proposal, is it worth retaining Binding Fault
> component? "wsoap:code", "wsoap:subcodes" and "whttp:code" and their
> corresponding properties can be attached to the proposed Binding Fault
> Reference component.
>
> Regards,
> Asir S Vedamuthu
> asirv at webmethods dot com
> http://www.webmethods.com/
>
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
> Behalf Of Roberto Chinnici
> Sent: Tuesday, November 16, 2004 9:47 PM
> To: www-ws-desc@w3.org
> Subject: Adding binding infault/outfault components (LC55)
>
>
>
> I had an action item to to write up the addition of infault and outfault
> at the binding level plus modifications of the component model. (LC55)
>
> Define a Binding Fault Reference component with the following properties:
>
>   {fault reference} REQUIRED - A Fault Reference component.
>   {features} OPTIONAL - A set of Feature components.
>   {properties} OPTIONAL - A set of Property components.
>
> The pseudo-schema for a binding operation would be updated to look like
> this:
>
>     <operation ref="xs:QName" >
>       <documentation />?
>
>       <input messageLabel="xs:NCName"? >
>         <documentation />?
>
>         <feature ... />*
>
>         <property ... />*
>       </input>*
>
>       <output messageLabel="xs:NCName"? >
>         <documentation />?
>
>         <feature ... />*
>
>         <property ... />*
>       </output>*
>
>       <infault ref="xs:QName" messageLabel="xs:NCName"?>
>         <documentation />?
>
>         <feature ... />*
>
>         <property ... />*
>       </infault>*
>
>       <outfault ref="xs:QName" messageLabel="xs:NCName"?>
>         <documentation />?
>
>         <feature ... />*
>
>         <property ... />*
>       </outfault>*
>
>       <feature ... />*
>
>       <property ... />*
>     </operation>*
>
> The mapping of a binding infault
>
>       <infault ref="xs:QName" messageLabel="xs:NCName"?>
>         <documentation />?
>
>         <feature ... />*
>
>         <property ... />*
>       </infault>*
>
> to a Binding Fault Reference component BFR would be as follows:
>
>   (the notation C.{P} denotes property {P} of component C)
>
>   1. start with the Binding Operation BO;
>   2. BO.{operation reference} is an Interface Operation component I;
>   3. I.{fault references} is a set of Fault Reference components;
>   4. the value of BFR.{fault reference} is the unique element FR of
I.{fault
> references} such that
>        a. FR.{fault reference}.{name} == the value of the @ref attribute
of
> wsdl:infault
>        b. FR.{message label} == the value of the @message label of
> wsdl:infault (*)
>        c. FR.{direction} == 'in'
>
> (*) For consistency with the mapping rules for the Fault Reference
> component, the @message
> attribute is optional provided that there is only one message in the MEP
> used by I whose
> corresponding fault has the 'in' direction (of course, taking the fault
rule
> used by the
> MEP into account).
>
> Similarly for a binding outfault, with 'out' in place of 'in'.
>
> In part 3, we'd extend the pseudo-schema so as to allow wsoap:module
inside
> the binding infault/outfault elements:
>
>     <operation ref="xs:QName"
>                whttp:location="xs:anyURI"??
>                whttp:transferCodingDefault="xs:string"?? >
>                wsoap:mep="xs:anyURI"?
>                wsoap:action="xs:anyURI"? >
>       <documentation />?
>
>       <wsoap:module ... />*
>
>       <input messageLabel="xs:NCName"?
>              whttp:transferCoding="xs:string"?? >
>         <documentation />?
>         <wsoap:module ... />*
>         <feature ... />*
>         <property ... />*
>       </input>*
>
>       <output messageLabel="xs:NCName"?
>              whttp:transferCoding="xs:string"?? >
>         <documentation />?
>         <wsoap:module ... />*
>         <feature ... />*
>         <property ... />*
>       </output>*
>
>       <infault ref="xs:QName" messageLabel="xs:NCName"?
>              whttp:transferCoding="xs:string"?? >
>         <documentation />?
>         <wsoap:module ... />*
>         <feature ... />*
>         <property ... />*
>       </infault>*
>
>       <outfault ref="xs:QName" messageLabel="xs:NCName"?
>              whttp:transferCoding="xs:string"?? >
>         <documentation />?
>         <wsoap:module ... />*
>         <feature ... />*
>         <property ... />*
>       </outfault>*
>
>       <feature ... />*
>       <property ... />*
>     </operation>*
>
> Section 2.6.2 would be amended so that the {soap modules} property becomes
> applicable to Binding Fault Reference components.
>
> Roberto
>
> -- 
> Roberto Chinnici
> Java Web Services
> Sun Microsystems, Inc.
> roberto.chinnici@sun.com

Received on Friday, 19 November 2004 20:03:08 UTC