- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Tue, 19 Nov 2002 05:09:28 -0800
- 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 UTC