- From: Liu, Kevin <kevin.liu@sap.com>
- Date: Thu, 18 Nov 2004 18:20:03 +0100
- To: "'Asir Vedamuthu'" <asirv@webmethods.com>, "'Roberto Chinnici'" <Roberto.Chinnici@Sun.COM>, www-ws-desc@w3.org
Asir, For your first proposal about adding a message reference to binding input/output, do you mean something like <binding...> .. <operation ref="xs:QName" > <documentation />? <input ref= "xs:Qname" messageLabel="xs:NCName"? > <documentation />? <feature ... />* <property ... />* </input>* ... If so, what do you think should be the value of the reference? Best Regards, Kevin >-----Original Message----- >From: www-ws-desc-request@w3.org >[mailto:www-ws-desc-request@w3.org] On Behalf Of Asir Vedamuthu >Sent: Thursday, Nov 18, 2004 07:29 AM >To: 'Roberto Chinnici'; www-ws-desc@w3.org >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 Thursday, 18 November 2004 17:20:44 UTC