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

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

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Mon, 3 Nov 2003 19:58:29 +0600
Message-ID: <02bb01c3a212$bd666020$10266a20@lankabook2>
To: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
Cc: "WS Description List" <www-ws-desc@w3.org>

Did you look at:

http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl20.html#Interfac
eOperationStyle

(Note the wsdl20.html part ..)

Sanjiva.

----- Original Message -----
From: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: "WS Description List" <www-ws-desc@w3.org>
Sent: Monday, November 03, 2003 4:18 AM
Subject: Re: RPC Style Issues Part (1) - spec updated


>
>
> Sanjiva Weerawarana wrote:
>
> >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.
> >
> >
> Sanjiva,
>
> I don't see any changes in the editor's copy. Perhaps there is a problem ?
>
> However, since there appears to be a confusion [1] as to what I was
> really asking for, I rewrote my suggestions incorporating all the
> rewording  proposal for the rules. Regardless of the discussions about
> the conformance that we need
> agreement upon, please have a look [2]. I believe the wording is clearer
> on all the rules (no more "foo" mentioned, etc).
>
> Thanks,
>
> --umit
>
> [1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0342.html
> [2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0007.html
>
>
> >----- 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#RP
C
> >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#At
t
> >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#At
t
> >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#XM
L
> >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#XM
L
> >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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> Umit Yalcinalp
> Consulting Member of Technical Staff
> ORACLE
> Phone: +1 650 607 6154
> Email: umit.yalcinalp@oracle.com
>
>
>
Received on Monday, 3 November 2003 08:59:10 GMT

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