- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Tue, 19 Nov 2002 06:44:04 -0500
- 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 UTC