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

+1.  Discussion among developers here was very favorable, with some concern expressed over backward compatibility.  In the end, though, that was judged worthy of sacrifice in the interest of this simplification and cleanup.

Amy!
On Thu, 7 Nov 2002 06:19:54 -0800
"David Orchard" <dorchard@bea.com> wrote:

> +1.  Anything that simplifies WSDL through re-use is good.
>  
> Cheers,
> Dave
> 
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Roberto Chinnici
> Sent: Wednesday, November 06, 2002 3:24 PM
> To: www-ws-desc@w3.org
> Subject: Proposal for the removal of the message construct from WSDL 1.2
>
> 
> 
> Proposal for the Removal of the Message Construct from WSDL 1.2
> 
> Roberto Chinnici <mailto:roberto.chinnici@sun.com> , Sun Microsystems,
> Inc.
> Martin  <mailto:mgudgin@microsoft.com> Gudgin, Microsoft
> Jeffrey Schlimmer <mailto:jeffsch@windows.microsoft.com> , Microsoft
> 
> 
> October 21st, 2002
> 
> introductionIntroduction
> 
> 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.
> 
> 
> problemstatementProblem 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,
> 
> 
> *	messages cannot extend other messages; 
> 
> *	message parts cannot be shared by messages
> 
> 
> *	message parts cannot be defined as being optional;
> 
> 
> *	message parts cannot have an associated multiplicity (e.g. "this
> part must appear at least twice");
> 
> 
> *	message parts are named by NCNAMEs, not qualified names; 
> 
> *	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. 
> 
> proposedresolutionProposed 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.
> 
> 
> consequencesConsequences
> 
> 
> 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, 
> 
> *	types can be derived from other types through either extension
> or restriction; 
> 
> *	the minOccurs and maxOccurs attributes can be used to specify
> cardinality constraints; 
> 
> *	the ref attribute allows for sharing of type or element
> components at any level of the description; 
> 
> *	local elements may have qualified names; 
> 
> *	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.
> 
> 
> examplesExamples
> 
> 
> 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/PrimerExampl
> es/example0">  
>         <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/PrimerExampl
> es/example0">     
>   <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/PrimerExampl
> es/example0">     
>   <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.
> 
> 
> 
> referencesReferences
> 
> ref1[ 1 <http://www.w3.org/TR/wsdl> ] Web Services Definition Language
> (WSDL) 1.1
> 
> 
> 
> 
> 
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 8 November 2002 11:24:40 UTC