- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Sat, 9 Nov 2002 08:13:15 -0500
- To: <www-ws-desc@w3.org>
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 Saturday, 9 November 2002 08:15:56 UTC