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

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

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Tue, 19 Nov 2002 05:09:28 -0800
Message-ID: <92456F6B84D1324C943905BEEAE0278E02D309FE@RED-MSG-10.redmond.corp.microsoft.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, "WS-Desc WG (Public)" <www-ws-desc@w3.org>

Was discussed at FTF: 

<xs:complexType name='foo'>
  <xs:sequence>
    <xs:element name='a' />
    <xs:element name='b' />
    <xs:element name='c' />
  </xs:sequence>
</xs:complexType>

<wsdl:input type='foo' />

Alternatively use named model groups:

<xs:group name='foo'>
  <xs:sequence>
    <xs:element name='a' />
    <xs:element name='b' />
    <xs:element name='c' />
  </xs:sequence>
</xs:group>

<wsdl:input group='foo' />

soap:header already refers directly to element/type.

Personally I'd model attachments using an element decl and figure out
the actual serialization in the binding.

Gudge

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
> Sent: 19 November 2002 11:44
> To: WS-Desc WG (Public)
> Subject: Fw: Proposal for the removal of the message 
> construct from WSDL 1.2
> 
> 
> 
> 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/Pr
> imerExamples/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/Pr
> imerExamples/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/Pr
> imerExamples/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 08:10:00 GMT

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