W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2003

RPC Style Issues Part (1)

From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
Date: Wed, 08 Oct 2003 21:05:48 -0700
Message-ID: <3F84DE9C.5010406@oracle.com>
To: WS Description List <www-ws-desc@w3.org>
I have reviewed the RPC rules [1] and found out the following problems.

-- The first paragraph of Section 2.3.1.1 is extremely confusing. This 
is primarily due to the presence of the last sentence in the first 
paragraph because this sentence implies that the rules are not 
normative. There are two issues that need to be clarified

(a) whether the rules that define a specific style are normative.
(b) whether they are required to be recognized by the WSDL processors. 

This issue  has also been debated somewhat in the wg but not resolved in 
our opinion.

It is Oracle's position that the last sentence must be removed to remove 
this confusion.

I propose that the rules are be divided into two groups. The first group 
explicitly states the schema and message content requirements that are 
normatively defined and required. The second group are those that were 
usually referred to as "hints" in the discussions.  The schema rules are 
not hints, they are simply constraints that must be understood. They are 
very minimal and do not pose a big burden on the WSDL processors.   
Consequently, the schema constraints MUST be required to be understood 
by all WSDL processors.

-- I tightened up the language a little bit. The editors would probably 
choose to add further clarifications/additions to what I propose. 
(Thanks to Schema speak).


Cheers,

--umit


          2.3.1.1 Operation Style

An Interface Operation component contains a {style} property. This 
property can only contain a URI value. However,  it is OPTIONAL for this 
property to have a value. If  the {style} property has a value, this 
implies specific rules that were used to define the {body} properties of 
all {message reference}s within that component designated by the URI. If 
this property has a given value, then the rules implied by that value 
(URI) MUST be followed.

This specification defines the following pre-defined operation styles:

    *

      RPC Style (see 2.3.1.1.1 RPC Style
      <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl12/wsdl12.html#RPCStyle>)

    *

      Set-Attribute Style (see 2.3.1.1.2 Set-Attribute Style
      <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl12/wsdl12.html#AttrSetStyle>)

    *

      Get-Attribute Style (see 2.3.1.1.3 Get-Attribute Style
      <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl12/wsdl12.html#AttrGetStyle>)


            2.3.1.1.1 RPC Style

The RPC style is selected by assigning the Interface Operation 
component's {style} property the value 
http://www.w3.org/@@@@/@@/wsdl/style/rpc.

Use of this value states that XML Schema [XML Schema: Structures 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl12/wsdl12.html#XMLSchemaP1>] 
was used to define the schemas of the {body} properties of all {message 
reference} components of the Interface Operation component. Those 
schemas MUST adhere to the following rules.

    *

      The content model of input and output {body} elements are defined
      by using a complex type that contains a sequence from XML Schema
      [XML Schema: Structures
      <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl12/wsdl12.html#XMLSchemaP1>].


    * The sequence can only contain elements. It MUST NOT contain other
      structures such as xs:choice.
    *

      The sequence MUST contain only local element children.

    *

      The child elements MAY contain the following attributes,
      xsi:Nillable, minOccurs and maxOccurs.

    *

      The localPart of input element's qname is be the same as the
      Interface operation component's name.

    *

      The localPart of the output element's qname is obtained by
      concatenating the name of the operation and the string value
      "Response", i.e. concat(operation/@name,"Response").

    *

      Input and output elements MUST  both be in the same namespace.

Furhermore, this style is used to indicate that the messages in fact 
capture a function signature. Hence, the following rules imply encoding 
of function signatures.

    *

      The child elements of input and output respectively represent
      input and output parameters of an operation. (similar to the
      message parts in WSDL 1.1)

    *

      An input parameter is indicated if an element is a child of the
      input element and an element with the same name is not a child of
      the output element.

    *

      An output element is indicated if an element is a child of the
      output element and an element with the same name is not a child of
      the input element.

    *

      An in/out parameter of a function is designated by an element that
      occurs both as a child element in the input and the output elements.


[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com


-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com
Received on Thursday, 9 October 2003 00:07:52 GMT

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