W3C home > Mailing lists > Public > www-ws-desc@w3.org > November 2004

RE: Adding binding infault/outfault components (LC55)

From: Asir Vedamuthu <asirv@webmethods.com>
Date: Thu, 18 Nov 2004 07:27:54 -0800
Message-ID: <5B10E50E14A4594EB1B5566B69AD9407068E68C4@maileast>
To: 'Roberto Chinnici' <Roberto.Chinnici@Sun.COM>, www-ws-desc@w3.org

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 15:28:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:33 GMT