Re: RPC Style Issues Part (1) - spec updated

I have updated replaced the "last sentence" referred to below with
an entire paragraph that tries to capture our intent. Please
read and let me know if it still requires clarification.

Sanjiva.

----- Original Message -----
From: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
To: "WS Description List" <www-ws-desc@w3.org>
Sent: Thursday, October 09, 2003 10:05 AM
Subject: RPC Style Issues Part (1)


> 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#RPC
Style>)
>
>     *
>
>       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#Att
rSetStyle>)
>
>     *
>
>       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#Att
rGetStyle>)
>
>
>             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#XML
SchemaP1>]
> 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#XML
SchemaP1>].
>
>
>     * 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 Sunday, 2 November 2003 05:13:14 UTC