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

Fw: Proposal for the removal of the message construct from WSDL 1.2

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Tue, 19 Nov 2002 06:44:04 -0500
Message-ID: <040201c28fc0$f8240c40$bc86400c@lankabook2>
To: "WS-Desc WG \(Public\)" <www-ws-desc@w3.org>

I don't recall seeing a response to this .. how would this
be modeled using the complexType proposal?

Sanjiva.

----- Original Message -----
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: <www-ws-desc@w3.org>
Sent: Saturday, November 09, 2002 8:13 AM
Subject: Re: Proposal for the removal of the message construct from WSDL 1.2


>
> I haven't read this carefully yet, but how would you describe
> the following with this:
>     <SOAP:Envelope>
>         <SOAP:Body>
>             <a/>
>             <b/>
>             <c/>
>         </SOAP:Body>
>     </SOAP:Envelope>
>
> What about attachments and headers?
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Roberto Chinnici" <roberto.chinnici@sun.com>
> To: <www-ws-desc@w3.org>
> Sent: Wednesday, November 06, 2002 6:24 PM
> Subject: Proposal for the removal of the message construct from WSDL 1.2
>
>
> > Gudge, Jeffrey and myself had an action item to write up a proposal to
> > remove
> > wsdl:message from the language. The proposal is attached. Since I'm
> > travelling
> > this week, I won't be able to reply promptly to emails on the subject,
> > but I'll
> > be happy to address any questions at the face-to-face meeting next week.
> >
> > Regards,
> > Roberto
> >
> >
>
>
> --------------------------------------------------------------------------
--
> ----
>
>
> > Removing wsdl:messageProposal for the Removal of the Message Construct
> from WSDL 1.2
> > Roberto Chinnici, Sun Microsystems, Inc.
> > Martin Gudgin, Microsoft
> > Jeffrey Schlimmer, Microsoft
> >
> >
> > October 21st, 2002
> > Introduction
> > The <wsdl:message/> construct has an unenviable status in WSDL 1.1 and
> 1.2. Underpowered and sandwiched between more interesting and semantically
> rich constructs (operations and types), it often appears to exist for
purely
> syntactic reasons.
> >
> > In this proposal, we explore how the removal of message from WSDL 1.2
> would pleasantly affect the language, giving tangible benefits to spec
> editors, extensions writers, service authors, tools writers and more.
> >
> > Problem Statement
> > The <wsdl:message/> construct describes a message as a list of parts of
> arbitrary types.
> >
> > The first problem that WSDL authors face is the limited expressiveness
of
> this construct. Several useful capabilities are completely absent. For
> instance,
> >
> >   a.. messages cannot extend other messages;
> >   b.. message parts cannot be shared by messages
> >
> >   c.. message parts cannot be defined as being optional;
> >
> >   d.. message parts cannot have an associated multiplicity (e.g. "this
> part must appear at least twice");
> >
> >   e.. message parts are named by NCNAMEs, not qualified names;
> >   f.. messages cannot be defined as being "extensible", i.e. as
accepting
> arbitrary parts in addition to those specified.
> >
> > Although some of these limitations could be addressed by extending the
> <wsdl:message/> and <wsdl:part/> constructs, we'd rather not duplicate
work
> done in other working groups. Moreover, it's always hard to determine
where
> we should draw the line when adding new features.
> >
> > Expressiveness aside, it's often the case that messages are superflous
and
> have to be present exclusively for syntactic reasons. Not only fault
> messages consist of just one part, but a common WSDL authoring style uses
> single-part input and output messages for all operations.
> >
> > Here's an example taken from the WSDL 1.1 specification ([1], Section
1.2,
> Example 1):
> >
> >           <types>
> >              <schema targetNamespace="http://example.com/stockquote.xsd"
> >                     xmlns="http://www.w3.org/2000/10/XMLSchema">
> >                  <element name="TradePriceRequest">
> >                     <complexType>
> >                         <all>
> >                             <element name="tickerSymbol" type="string"/>
> >                         </all>
> >                     </complexType>
> >                  </element>
> >                  <element name="TradePrice">
> >                     <complexType>
> >                         <all>
> >                             <element name="price" type="float"/>
> >                         </all>
> >                     </complexType>
> >                  </element>
> >              </schema>
> >           </types>
> >
> >           <message name="GetLastTradePriceInput">
> >               <part name="body" element="xsd1:TradePriceRequest"/>
> >           </message>
> >
> >           <message name="GetLastTradePriceOutput">
> >               <part name="body" element="xsd1:TradePrice"/>
> >           </message>
> >
> >           <portType name="StockQuotePortType">
> >               <operation name="GetLastTradePrice">
> >                  <input message="tns:GetLastTradePriceInput"/>
> >                  <output message="tns:GetLastTradePriceOutput"/>
> >               </operation>
> >           </portType>
> >
> >
> > In addition to the presence of single-part messages, another hint that
> messages can safely be dispensed with comes from the naming convention
used
> in the example above (and, incidentally, by countless other WSDL
documents).
> In particular, notice how the names of the input and output messages for
an
> operation (e.g, GetLastTradePriceInput and GetLastTradePriceOutput) mirror
> the names of the XML Schema element declarations (TradePriceRequest and
> TradePrice). Clearly, if the latter were used directly when declaring a
> <wdsl:operation/>, no loss of information would occur. As yet an
additional
> hint of the artificiality of the part construct itself, consider some of
the
> names typically given to parts of a message: "body", "parameters",
> "arguments", "result" -- all as generic and non-descript as possible.
> >
> > Richness and meaningfulness of messages aside, one additional problem is
> that faced by the authors of a WSDL binding extension.
> >
> > As things stand today, bindings must deal with (at least) two different
> packaging/typing constructs, namely <wsdl:message/> and <xsd:complexType/>
> (or <xsd:element/>): the former applies only to the top-level, while the
> second one can go arbitrarily deep.
> > Consequently, when the author of a binding wants to describe the result
of
> applying the binding rules to a <wsdl:operation/>, he is forced to give a
> first description in terms of message parts, then refine it to say how
parts
> are to be mapped based on their type.
> > Proposed Resolution
> > We propose eliminating the <wsdl:message> construct altogether.
> >
> > In lieu of messages, portType operations would use their favorite type
> system to describe their input, output and fault messages.
> >
> > The type system extensibility features currently built in the
<wsdl:part/>
> element would be moved to the <wsdl:input/>, <wsdl:output/> and
> <wsdl:fault/> elements. In particular, those elements would accept one of
> the predefined "type" and "element" attributes, used to refer to XML
Schema
> type definitions and element declarations respectively, as well as other
> arbitrary namespace-qualified attributes to allow WSDL authors to use
> arbitrary type systems.
> >
> > The component model would undergo a corresponding change. In particular,
> "message" and "part" components would disappear, while "message reference"
> components would acquire some of the properties currently associated with
> parts.
> >
> > Consequences
> >
> > Unlike <wsdl:message/>, the XML Schema type system is feature-rich, so
> that the limitations listed in the "Problem Statement" section above do
not
> apply. More explicitely,
> >   a.. types can be derived from other types through either extension or
> restriction;
> >   b.. the minOccurs and maxOccurs attributes can be used to specify
> cardinality constraints;
> >   c.. the ref attribute allows for sharing of type or element components
> at any level of the description;
> >   d.. local elements may have qualified names;
> >   e.. the xsd:any construct provides support for extensible content
> models.
> >
> > There's also a host of other advanced features that XML Schema
possesses,
> such as substitution groups, that would suddenly become available to WSDL
> authors as they define the input and output message formats for their
> operations. Such features are simply unimaginable with the current
> <wsdl:message/> construct, and we look forward to seeing how they'll be
> employed should this proposal be accepted.
> >
> > Since current usage tells us that the XML Schema type system is already
> used by the vast majority of WSDL 1.1 documents, this proposal would
enable
> WSDL processors to manipulate messages through their XML Schema
descriptions
> alone.
> >
> > Similarly, binding authors could use XPath and other XML-related
> technologies without having to introduce special syntax to deal with
> messages and parts, as was the case in WSDL 1.1. For instance, the result
of
> applying a binding to a "message type" could be fully described using
XSLT.
> It's also worth pointing out that the working group has already started
> taking steps in that direction, as witnessed by the changes to the
> <soap:header/> element approved at the last face to face meeting.
> >
> > The case of other type systems can be readily accommodated by using the
> extensible nature of the <wsdl:input/>, <wsdl:output/> and <wsdl:fault/>
> element. Any type system worth its name will provide structuring
constructs
> at least as powerful as <wsdl:message/>, so the removal of <wsdl:message/>
> won't be felt as a limitation. Rather, the ability to use the full power
of
> the native type system will be energizing, just as for XML Schema.
> >
> > A case that isn't directly addressed by this proposal is that of a
> <wsdl:message/> with parts described using different type systems. Until
> today, this case has been mostly of theoretical interest only, except in
one
> case described below. In general, there is a range of solutions available,
> going from embedding all those type systems inside the XML Schema one to
> defining a new packaging construct specially for this purpose. Although
> we're not convinced of the usefulness of this "multiple type systems"
> scenario, we think that our proposal does not in any way prevent
determined
> WSDL authors from using it.
> >
> > There is a special case, namely the combination of XML Schema and MIME
> types, that is worth spelling out in detail.
> >
> > In WSDL 1.1, MIME types were not specified at the message part level;
> rather, they were listed in the MIME binding extension. For WSDL 1.2,
there
> is definitely some interest in allowing MIME types to be used at the
> abstract level.
> >
> > We believe that this proposal doesn't make using MIME types any harder,
> and that any satisfactory solution that used the <wsdl:message/> and
> <wsdl:part/> constructs could be rephrased in terms of XML Schema. (For
> instance, XML Schema type definitions could be annotated with a
> mime:typeattribute. Or new type definitions, in their own namespace, could
> be created for all MIME types.) So we propose that the working group
address
> the issue of using MIME types alongside XML Schema types as part of a
> separate issue, independent of the present one.
> >
> > Examples
> >
> > Consider the following WSDL 1.2 fragment (adapted from the Primer):
> >
> >         <message name="inReserveRoom">
> >             <part name="customerName" type="xs:string"/>
> >             <part name="checkInDate" type="xs:date"/>
> >             <part name="checkOutDate" type="xs:date"/>
> >             <part name="roomType" type="xs:string"/>
> >             <part name="comments" type="xs:string"/>
> >             <part name="agentID" type="xs:string"/>
> >         </message>
> >         <message name="outReserveRoom">
> >             <part name="roomRate" type="xs:double"/>
> >             <part name="reservationID" type="xs:string"/>
> >         </message>
> >
> >         <operation name="ReserveRoom">
> >             <input message="inReserveRoom"/>
> >             <output message="outMessage"/>
> >         </operation>
> >
> >
> >
> > With our proposal, it would be rewritten as follows:
> >   <types>
> >             <xs:schema elementFormDefault="qualified"
>
targetNamespace="http://www.w3.org/webServicesDescription12/PrimerExamples/e
> xample0">
> >                 <xs:complexType name="tReserveRoomInput">
> >                     <xs:sequence>
> >                         <xs:element name="customerName"
type="xs:string"/>
> >                         <xs:element  name="checkInDate" type="xs:date"/>
> >                         <xs:element  name="checkOutDate"
type="xs:date"/>
> >                         <xs:element  name="roomType" type="xs:string"/>
> >                         <xs:element  name="comments"
element="xs:string"/>
> >                         <xs:element  name="agentID" type="xs:string"/>
> >                     </xs:sequence>
> >                 </xs:complexType>
> >                 <xs:complexType name="tReserveRoomOutput">
> >                     <xs:sequence>
> >                         <xs:element name="roomRate" type="xs:double"/>
> >                         <xs:element name="reservationID"
> type="xs:string"/>
> >                     </xs:sequence>
> >                 </xs:complexType>
> >             </xs:schema>
> >         </types>
> >
> >         <operation name="ReserveRoom">
> >             <input type="typens:tReserveRoomInput"/>
> >             <output type="typens:tReserveRoomOutput"/>
> >         </operation>
> >
> >
> >
> > As shown above, the XML Schema type system can be readily used to
replace
> the less powerful <wsdl:message/> construct.
> >
> > Another example from the primer shows how superflous messages are
whenever
> WSDL authors have already come up with a suitable XML Schema description
of
> the fragments they intend to exchange. Here's the relevant WSDL fragment
in
> the current syntax:
> >   <types>
> >          <xs:schema elementFormDefault="qualified"
>
targetNamespace="http://www.w3.org/webServicesDescription12/PrimerExamples/e
> xample0">
> >           <xs:complexType name="tInReserveRoom">
> >            <xs:sequence>
> >             <xs:element name="customerName" type="xs:string"/>
> >             <xs:element name="checkInDate" type="xs:date"/>
> >             <xs:element name="checkOutDate" type="xs:date"/>
> >             <xs:element name="roomType" type="xs:string"/>
> >             <xs:element name="comments" element="xs:string"/>
> >             <xs:element name="agentID" type="xs:string"/>
> >            </xs:sequence>
> >           </xs:complexType>
> >          </xs:schema>
> >         <xs:complexType name="tOutReserveRoom">
> >         <xs:sequence>
> >         <xs:element name="roomRate" type="xs:double"/>
> >         <xs:element name="reservationID" type="xs:string"/>
> >         </xs:sequence>
> >         </xs:complexType>
> >         </types>
> >         <message name="inReserveRoom">
> >          <part name="ReserveRoom" type="typens:tInReserveRoom"/>
> >         </message>
> >
> >         <message name="outReserveRoom">
> >          <part name="ReserveRoom" type="typens:tOutReserveRoom"/>
> >         </message>
> >
> >         <operation name="ReserveRoom">
> >             <input message="inReserveRoom"/>
> >             <output message="outReserveRoom"/>
> >         </operation>
> >
> >
> >
> > And here's the corresponding fragment with the proposed new syntax:
> >   <types>
> >          <xs:schema elementFormDefault="qualified"
>
targetNamespace="http://www.w3.org/webServicesDescription12/PrimerExamples/e
> xample0">
> >           <xs:complexType name="tInReserveRoom">
> >            <xs:sequence>
> >             <xs:element name="customerName" type="xs:string"/>
> >             <xs:element name="checkInDate" type="xs:date"/>
> >             <xs:element name="checkOutDate" type="xs:date"/>
> >             <xs:element name="roomType" type="xs:string"/>
> >             <xs:element name="comments" element="xs:string"/>
> >             <xs:element name="agentID" type="xs:string"/>
> >            </xs:sequence>
> >           </xs:complexType>
> >          </xs:schema>
> >          <xs:complexType name="tOutReserveRoom">
> >           <xs:sequence>
> >            <xs:element name="roomRate" type="xs:double"/>
> >            <xs:element name="reservationID" type="xs:string"/>
> >           </xs:sequence>
> >          </xs:complexType>
> >         </types>
> >
> >         <operation name="ReserveRoom">
> >             <input type="typens:tInReserveRoom"/>
> >             <output type="typens:tOutReserveRoom"/>
> >         </operation>
> >
> >
> >
> > Clearly, the message definitions in the first fragment are completely
> superflous and serve a syntactic purpose only. There is literally NO use
of
> the message components in the first fragment that cannot be reproduced
with
> the approach exemplified in the second fragment. Moreover, the latter
allows
> for derivation of messages (and much more) while the first one does not.
> >
> >
> > References
> > [1] Web Services Definition Language (WSDL) 1.1
> >
> >
> >
> >
> >
Received on Tuesday, 19 November 2002 06:46:34 GMT

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