This document describes the Web Services Description Language (WSDL) Version 2.0, an XML language for describing Web services. This specification defines the core language which can be used to describe Web services based on an abstract model of what the service offers. It also defines criteria for a conformant processor of this language.
This is a
A
This document has been produced as part of the
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Comments on this document are invited and are to be sent to the
public
This document has been produced under the
Last Modified: $Date: 2004/03/26 16:30:30 $
Web Services Description Language (WSDL) provides a model and an XML format for describing Web services. WSDL enables one to separate the description of the abstract functionality offered by a service from concrete details of a service description such as "how" and "where" that functionality is offered.
This specification defines a language for describing the abstract
functionality of a service as well as a framework for describing the
concrete details of a service description.
It also defines criteria for a conformant processor of this language.
The
WSDL describes a Web service in two fundamental stages: one abstract and one concrete. Within each stage, the description uses a number of constructs to promote reusability of the description and separate independent design concerns.
At an abstract level, WSDL describes a Web service in terms of the messages it sends and receives; messages are described independent of a specific wire format using a type system, typically XML Schema.
An
At a concrete level, a
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
This specification uses properties from the XML Information Set
This specification uses namespace prefixes throughout; they are
listed in
Prefix | Namespace | Notes |
---|---|---|
wsdl | A normative XML Schema |
|
wsdli | A normative XML Schema |
|
wrpc | A normative XML Schema |
|
wsoap12 | Defined by WSDL 2.0: Bindings |
|
whttp | ||
xs | Defined in the W3C XML Schema
specification |
|
xsi |
Namespace names of the general form
All parts of this specification are normative, with the EXCEPTION of notes, pseudo-schemas, examples, and sections explicitly marked as "Non-Normative". Pseudo-schemas are provided for each component, before the description of the component.
This section describes the conceptual model for WSDL as a set of components with properties, each aspect of a Web service that WSDL can describe having its own property. In addition an XML Infoset representation for these components is provided, along with a mapping from that representation to the various component properties. How the XML Infoset representation of a given set of WSDL components is constructed is outside the scope of this specification.
At the abstract level, the Definitions component is just a container for two categories of components; WSDL components and type system components.
WSDL components are interfaces, bindings and services.
Type system components are element declarations drawn from
some type system. They define the [local name], [namespace name],
[children] and [attributes] properties of an
The properties of the Definitions component are as follows:
{interfaces} A set of named interface definitions
{bindings} A set of named binding definitions
{services} A set of named service definitions
{element declarations} A set of named element declarations, each one isomorphic to a global element declaration as defined by XML Schema
The set of interfaces/binding/services/etc. available in the Definitions component include those that are defined within the component itself and those that are imported and/or included. Note that at the component model level, there is no distinction between directly defined components vs. imported/included components.
The components directly defined within a single Definitions
component are said to belong to the same
Note that it is RECOMMENDED that the value of the
If a service description is split into multiple documents
(which may be combined as needed via
Imported components have different target namespace values from the Definitions component that is importing them. Thus importing is the mechanism to use components from one namespace in another set of definitions.
Each WSDL or type system component MUST be uniquely identified by its qualified name. That is, if two distinct components of the same kind (Interface, Binding etc.) are in the same target namespace, then their QNames MUST be unique. However, different kinds of components (e.g., an Interface component and a Binding component) MAY have the same QName. Thus, QNames of components must be unique within the space of those components in a given target namespace.
In addition to WSDL components and type system
components, additional extension components MAY be added via
extensibility
WSDL definitions are represented in XML by one or more WSDL
Information Sets (Infosets), that is one or more
The targetNamespace URI MUST be an absolute URI (see
The
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more
Zero or more
Zero or more
Zero or more namespace-qualified
An OPTIONAL
Zero or more
Zero or more namespace-qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Definitions component
(see
Property | Mapping |
---|---|
{interfaces} |
The interface definitions corresponding to all
the |
{bindings} |
The binding definitions corresponding to all
the |
{services} |
The service definitions corresponding to all
the |
{element declarations} |
The element declaration components
corresponding to all the element declarations
defined as descendants of the |
An Interface component describes sequences of messages that a service sends and/or receives. It does this by grouping related messages into operations. An operation is a sequence of input and output messages, an interface is a set of operations.
An interface can optionally extend one or more other interfaces. In such cases the interface contains the operations of the interfaces it extends, along with any operations it defines. The interfaces a given interface extends MUST NOT themselves extend that interface either directly or indirectly.
Interfaces are named constructs and can be referred to by
QName (see
The properties of the Interface component are as follows:
{name} An NCName as defined by
{target namespace} A namespace name, as defined
in
{extended interfaces} A set of named interface definitions which this interface extends.
{faults} A set of named interface fault definitions.
{operations} A set of named interface operation definitions.
{features} A set of named feature definitions.
{properties} A set of named property definitions.
For each Interface component in the {interfaces} property of a definitions container, the combination of {name} and {target namespace} properties MUST be unique.
The XML representation for an Interface component is
an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
An OPTIONAL
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more
Zero or more
Zero or more
Zero or more
Zero or more
Zero or more namespace-qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value.
The type of the
The mapping between the properties of the Interface component (see
Property | Mapping |
---|---|
{name} | The actual value of the |
{target namespace} |
The actual value of the |
{extended interfaces} |
The set of interface definitions resolved to
by the values in the |
{faults} |
The set of interface fault definitions
corresponding to the |
{operations} |
The set of interface operation definitions
corresponding to the |
{features} |
The set of feature definitions corresponding
to the |
{properties} |
The set of property definitions corresponding
to the |
Note that, per
An Interface Fault component describes a fault that MAY be
occur during execution of an operation of the
interface. The Interface Fault component declares a fault
by naming it and indicating the content or payload of the
fault message. When and how the fault message flows is
indicated by the Interface Operation component
The reason the Interface Fault component is a property of the Interface component is because that provides a convenient mechanism to declare a set of fault message types and then indicate which operations use those types, thus allowing one to easily indicate that the same fault message type can occur in multiple operations.
The properties of the Interface Fault component are as follows:
{name} An NCName as defined by
{element} A reference to an XML element
declaration in the {element declarations} property of
If a non-XML type system is in use (as considered in
For each Interface Fault component in the {faults} property of an Interface component, the combination of {name} and {target namespace} properties must be unique.
Interface Fault components are local to Interface components; they cannot be referred to by QName, despite having both {name} and {target namespace} properties. That is, two Interface components sharing the same {target namespace} property but with different {name} properties MAY contain Interface Fault components which share the same {name} property. Thus, the {name} and {target namespace} properties of the Interface Fault components are not sufficient to form the unique identity of an Interface Fault component. To uniquely identify an Interface Fault component one must first identify the Interface component (by QName) and then identify the Interface Fault within that Interface component (by a further QName).
In cases where, due to an interface extending one or more
other interfaces, two or more Interface Faults components
have the same value for their {name} and {target namespace}
properties, then the component models of those Interface
Fault components MUST be equivalent (see
Note that, due to the above rules, if two interfaces that have the same value for their {target namespace} property also have one or more faults that have the same value for their {name} property then those two interfaces cannot both form part of the derivation chain of a derived interface unless those faults are the same fault.
For the above reason, it is considered good practice to ensure, where necessary, that the {name} property of Interface Fault components within a namespace are unique, thus allowing such derivation to occur without inadvertent error.
The XML representation for an Interface Fault component is an
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value.
The type of the
The mapping between the properties of the Interface Fault
component (see
Property | Mapping |
---|---|
{name} | The actual value of the |
{target namespace} |
The actual value of the
|
{element} | The element declaration
from the {element declarations} property of
|
An Interface Operation component describes an operation
that a given interface supports. An operation is an
interaction with the service consisting of a set (ordinary and
fault) messages exchanged between the service and the other
roles involved in the interaction, in particular the service
requestor. The sequencing and cardinality of the messages
involved in a particular interaction is governed by the
A message exchange pattern defines placeholders for messages, the
participants in the pattern (i.e., the sources and sinks of
the messages), and the cardinality and sequencing of messages
exchanged by the participants. The message placeholders are
associated with specific message types by the operation that uses
the pattern by means of message and fault references (see {message
references} and {fault references} properties). The service
whose operation is using the pattern becomes one of the
participants of the pattern. This specification does not
define a machine understandable language for defining message
exchange patterns, nor does it define any specific patterns. The companion
specification,
The properties of the Interface Operation component are as follows:
{name} An NCName as defined by
{target namespace} A namespace name, as defined in
{message exchange pattern} A URI identifying the
message exchange pattern used by the operation. This URI
MUST be an absolute URI (see
{message references} A set of Message Reference
components for the ordinary messages the operation accepts
or sends. (See
{fault references} A set of Fault Reference
components for the fault messages the operation accepts or
sends. (See
{style} A URI identifying the rules that were
used to construct the {element} properties of {message
references}. (See
{safety} A boolean indicating whether the
operation is asserted to be safe (as defined in Section
3.5 of
{features} A set of named feature definitions used by the operation
{properties} A set of named property definitions used by the operation
For each Interface Operation component in the {operations} property of an Interface component, the combination of {name} and {target namespace} properties MUST be unique.
Interface Operation components are local to Interface components; they cannot be referred to by QName, despite having both {name} and {target namespace} properties. That is, two Interface components sharing the same {target namespace} property but with different {name} properties MAY contain Interface Operation components which share the same {name} property. Thus, the {name} and {target namespace} properties of the Interface Operation components are not sufficient to uniquely identify an Interface Operation component. In order to uniquely identify an Interface Operation component, one must first identify the Interface component (by QName) and then identify the Interface Operation within that Interface component (by a further QName).
In cases where, due to an interface extending one or more
other interfaces, two or more Interface Operation components
have the same value for their {name} and {target namespace}
properties, then the component models of those Interface
Operation components MUST be equivalent (see
Note that, due to the above rules, if two interfaces that have the same value for their {target namespace} property also have one or more operations that have the same value for their {name} property then those two interfaces cannot both form part of the derivation chain of a derived interface unless those operations are the same operation.
For the above reason, it is considered good practice to ensure, where necessary, that the {name} property of Interface Operation components within a namespace are unique, thus allowing such derivation to occur without inadvertent error.
If the {style} property of an Interface Operation component
has a value then that value (a URI) implies the rules that
were used to define the {element} properties (or other
property which defines the content of the message properties;
see
This specification defines the following pre-defined operation style:
RPC Style (see
The XML representation for an Interface Operation component is an
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
A REQUIRED
An OPTIONAL
An OPTIONAL
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more
Zero or more
Zero or more
Zero or more
Zero or more
A
A
Zero or more namespace-qualified
At least one of the [children] MUST be an
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Interface
Operation component (see
Property | Mapping |
---|---|
{name} | The actual value of the |
{target namespace} |
The actual value of the |
{message exchange pattern} | The actual value of the |
{message references} |
The set of message references corresponding to
the |
{fault references} |
The set of fault references corresponding to the
|
{style} |
The actual value of the |
{safety} |
The actual value of the |
{features} |
The set of features corresponding to the
|
{properties} |
The set of properties corresponding to the
|
The RPC style is selected by assigning to an Interface
Operation component's {style} property the value
The RPC style MUST NOT be used for Interface Operation components whose {message exchange pattern} property has a value other than 'http://www.w3.org/2004/03/wsdl/in-only' or 'http://www.w3.org/2004/03/wsdl/in-out'.
Use of this value indicates that XML Schema
Note that if the Interface Operation component uses the {message exchange pattern} 'http://www.w3.org/2004/03/wsdl/in-only' then there is no output element and hence the rules which refer to the output element do not apply.
The content model of input and output {element} elements are defined using a complex type that contains a sequence from XML Schema.
The sequence MUST only contain elements. It MUST NOT contain other structures such as xs:choice.
The sequence MUST contain only local element children. Note that these child elements MAY contain the following attributes: nillable, minOccurs and maxOccurs.
The LocalPart of input element's QName MUST be the same as the Interface operation component's name.
The LocalPart of the output element's QName is obtained by concatenating the name of the operation and the string value "Response", i.e. concat(operation/@name,"Response").
Input and output elements MUST both be in the same namespace.
The complex type that defines the body of an input or an output element MUST NOT contain any attributes.
If elements with the same qualified name appear as children of both the input and output elements, then they MUST both be declared using the same type.
The input or output sequence MUST NOT contain multiple children elements declared with the same name.
The
When present, the
{rpc-signature} A (possibly empty) list of pairs
The value of the {rpc-signature} property MUST satisfy the following conditions:
The value of the first component of each pair
For each child element of the input and output messages of the operation,
a pair
For each pair
For each pair
For each pair
For each pair
The function signature defined by a Start with the value of the {rpc-signature} property, a (possibly empty)
list of pairs of this form: Filter the elements of this list into two lists, the first one For ease of visualization, let's denote the two lists as (L1) and (L2) respectively. Then the formal signature of the function is i.e.
the list of formal arguments to the function is the direction of each formal argument the list of formal return parameters of the function is
each formal argument and formal return parameter is typed
according to the type of the child element identified by it
(unique per the conditions given above).
The XML representation for the RPC signature extension is an
A [local name] of
A [namespace name] of "http://www.w3.org/2004/03/wsdl/rpc"
The type of the
Additionally, each even-numbered item (0, 2, 4, ...) in the list
MUST be of type
A
Property | Mapping |
---|---|
{rpc-signature} | A list of |
A Message Reference component associates to a message exchanged in an operation an XML element declaration that specifies its message content.
Message Reference components are identified by the role the
message plays in the {message exchange pattern} that the
operation is using. That is, a message exchange pattern
defines a set /meof placeholder messages that participate in the
pattern and assigns them unique names within the pattern. The
purpose of a Message Reference component is to associate an
actual message type (XML element declaration or some other
declaration (see
The properties of the Message Reference component are as follows:
{message label} An NCName as defined by
{direction} One of
{message content model} A token with one of the
values
{element} A reference to an XML element
declaration in the {element declarations} property of
If a non-XML type system is in use (as considered in
For each Message Reference component in the {message references} property of an Interface Operation component, its {message label} property MUST be unique.
The XML representation for a Message Reference component is
an
A [local name] of
A [namespace name] of
Zero or more
An OPTIONAL
If the {message exchange pattern} of the Interface
Operation component has only one message with a given value
for {direction}, then the
An OPTIONAL
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
A [local name] of
A [namespace name] which has no value.
The type of the
The mapping between the properties of the Message Reference
component (see
Property | Mapping |
---|---|
{message label} | The actual value of the |
{direction} | If the [local name] of the |
{message content model} | If the
|
{element} | If the |
A Fault Reference component associates a Fault component that defines the fault message type for a fault that occurs related to a message participating in an operation.
Fault Reference components are identified by the role the related message plays in the {message exchange pattern} that the operation is using. That is, a message exchange pattern defines a set of placeholder messages that participate in the pattern and assigns them unique labels within the pattern. The purpose of a Fault Reference component is to associate an actual Fault component for the fault that will occur with a specific message in the message exchange pattern.
The companion specification
More than one Fault Reference component may refer to the same message label. This allows one to indicate that there is more than one type of fault that is related to that message.
The properties of the Fault Reference component are as follows:
{message label} An NCName as defined by
{direction} One of
{fault reference} A reference to a Fault component in the {faults} property of the parent Interface Operation component's parent Interface component. Identifying the Fault component therefore indirectly defines the actual content or payload of the fault message.
The XML representation for a Fault Reference component is
an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
If the {message exchange pattern} of the Interface
Operation component has only one message with a given value
for {direction}, the
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Fault Reference
component (see
Property | Mapping |
---|---|
{fault reference} | The actual value of the |
{message label} | The actual value of
the |
{direction} | If the [local name] of the |
A feature component describes an abstract piece of functionality typically associated with the exchange of messages between communicating parties. Although WSDL poses no constraints on the potential scope of such features, examples might include "reliability", "security", "correlation", and "routing". The presence of a feature component in a WSDL description indicates that the service supports the feature and may require a requester agent that interacts with the service to use that feature. Each Feature is identified by its URI.
The properties of the Feature component are as follows:
{name} An absolute URI as defined by
{required} A boolean value. If the {require} property is true, then the requester agent MUST use the Feature that is identified by the {name} URI. Otherwise, the requester agent MAY use the Feature that is identified by the {name} URI. In either case, if the requester agent does use the Feature that is identified by the {name} URI, then the requester agent MUST obey all semantics implied by the definition of that Feature.
The set of features which are required or available for a given service and a particular interaction consists of the combined set of ALL feature declarations in the following scope. The list is in order of increasing specificity.
The interface component.
The specific interface operation component.
The specific message reference component.
The binding component.
The specific binding operation component.
The specific binding message or fault reference component.
Note that multiple declarations of the same feature have no effect on the
combined set of active features, since features are either in use or not,
with no multiplicity. If multiple declarations of the same feature are in
scope for a given interaction, the feature is required if ANY of the in
scope declarations have the
In the following example, the
The XML representation for a Feature component is an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Feature component (see
Property | Mapping |
---|---|
{name} | The actual value of the |
{required} |
If the value of the |
A Property component describes the set of possible values for a particular property. The permissible values are specified by references to a Schema description. A property is typically used to control a feature's behavior. Properties, and hence property values, can be shared amongst features.
The properties of the Property component are as follows:
{name} An absolute URI as defined by
{required} A boolean value. If the {required} property is true, then the requester agent MUST use the Property that is identified by the {name} URI. Otherwise, the requester agent MAY use the Property that is identified by the {name} URI. In either case, if the requester agent does use the Property that is identified by the {name} URI, then the requester agent MUST obey all semantics implied by the definition of that Property.
{value constraint} A type definition constraining the value of the property.
{value} The value of the property.
At runtime, the behaviour of features, (SOAP) modules and bindings may be affected by the values of in-scope properties. Properties combine into a virtual "execution context" which maps property names (URIs) to constraints. Each property URI MAY therefore be associated with AT MOST one property constraint for a given interaction.
The particular set of constraints for a given service and a particular interaction consists of the combined set of ALL constraints in the following scope. The list is in order of increasing specificity, and if a given property URI is constrained in a later scope, it overrides the earlier constraint.
The interface component.
The specific interface operation component.
The specific message reference component.
The binding component.
The specific binding operation component.
The specific binding message or fault reference component.
Note that, in the text above, "property constraint" (or, simply, "constraint")
is used to mean EITHER a
The XML representation for a Property component is an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
One or more
An OPTIONAL
One REQUIRED
A
A
Zero or more namespace-qualified
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
A [local name] of
A [namespace name] of
The type of the
The
A [local name] of
A [namespace name] of
The type of the
The mapping between the properties of the Property component (see
Property | Mapping |
---|---|
{name} | The actual value of the |
{value constraint} | If the
|
{value} | The actual value of the |
A Binding component describes a concrete message format and
transmission protocol which may be used to define an endpoint
(see
If a Binding component specifies any operation-specific binding details (by including Binding Operation components) or any fault binding details (by including Binding Fault components) then it MUST specify an interface the Binding component applies to, so as to indicate which interface the operations come from.
Conversely, a Binding component which omits any operation-specific binding details and any fault binding details MAY omit specifying an interface. Binding components that do not specify an interface MAY be used to specify operation-independent binding details for Service components with different interfaces. That is, such Binding components are reusable across one or more interfaces.
No concrete binding details are given in this
specification. The companion specification,
A Binding component which defines bindings for an Interface
component MUST define bindings for all the operations of that
Interface component. The bindings may occur via defaulting rules
which allow one to specify default bindings for all operations
(see, for example
Bindings are named constructs and can be referred to by
QName (see
The properties of the Binding component are as follows:
{name} An NCName as defined by
{target namespace} A namespace name, as defined
in
{interface} An named interface definition indicating the interface for which binding information is being specified.
{faults} A set of named binding fault definitions.
{operations} A set of named binding operation definitions.
{features} A set of named feature definitions.
{properties} A set of named property definitions.
For each Binding component in the {bindings} property of a definitions container, the combination of {name} and {target namespace} properties must be unique.
The XML representation for a Binding component
is an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more
Zero or more
Zero or more
Zero or more
Zero or more
Zero or more namespace-qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
Binding extension elements are used to provide
information specific to a particular binding. The semantics
of such
The mapping between the properties of the Binding component
(see
Property | Mapping |
---|---|
{name} | The actual value of the |
{target namespace} |
The actual value of the |
{interface} |
The Interface component resolved to by the actual value
of the |
{faults} | The set of
Binding Fault components corresponding to the
|
{operations} | The set of Binding
Operation components corresponding to the
|
{features} | The set of Feature components corresponding
to the |
{properties} | The set of Property components corresponding
to the |
A Binding Fault component describes a concrete binding of a particular fault within an interface to a particular concrete message format. A particular fault of an interface is uniquely identified by the target namespace of the interface and the name of the fault within that interface.
Note that the fault does not occur by itself - it occurs as part of a message exchange as defined by an Interface Operation component (and its binding counterpart the Binding Operation component). Thus, the fault binding information specified in a Binding Fault component describes how faults that occur within a message exchange of an operation will be formatted.
The properties of the Binding Fault component are as follows:
{fault reference} A QName as defined by
For each Binding Fault component in the {faults} property of a Binding component, the {fault reference} property MUST be unique. That is, one cannot define multiple bindings for the same fault within a given Binding component.
The XML representation for a Binding Fault component
is an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
The
A [local name] of
A [namespace name] which has no value
The type of the
Binding Fault extension elements are used to provide
information specific to a particular fault in a
binding. The semantics of such
The mapping between the properties of the Binding Fault
component (see
Property | Mapping |
---|---|
{fault reference} | The actual value of the |
A Binding Operation component describes a concrete binding of a particular operation of an interface to a particular concrete message format. A particular operation of an interface is uniquely identified by the target namespace of the interface and the name of the operation within that interface.
The properties of the Binding Operation component are as follows:
{operation reference} A QName as defined by
{message references} A set of Binding Message Reference components
For each Binding Operation component in the {operations} property of a Binding component, the {operation reference} property MUST be unique. That is, one cannot define multiple bindings for the same operation within a given Binding component.
Interface Operation components are local to Interface components; they cannot be referred to by QName, despite having both {name} and {target namespace} properties. That is, two Interface components sharing the same {target namespace} property but with different {name} properties MAY contain Interface Operation components which share the same {name} property. Thus, the {name} and {target namespace} properties of the Interface Operation components are not sufficient to form the unique identity of an Interface Operation component. To uniquely identify an Interface Operation component one must first identify the Interface component (by QName) and then identify the Interface Operation within that Interface component (by a further QName).
The XML representation for a Binding Operation component
is an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more
Zero or more
Zero or more
Zero or more
Zero or more
Zero or more namespace-qualified
The
A [local name] of
A [namespace name] which has no value
The type of the
Binding Operation extension elements are used to provide
information specific to a particular operation in a
binding. The semantics of such
The mapping between the properties of the Binding Operation
component (see
Property | Mapping |
---|---|
{operation reference} | The actual value of the |
{messages references} | The set of Binding Message Reference
components corresponding to the |
{features} | The set of Feature components corresponding
to the |
{properties} | The set of Property components corresponding
to the |
A Binding Message Reference component describes a concrete binding of a particular message participating in an operation to a particular concrete message format.
The properties of the Binding Message Reference component are as follows:
{message label} An NCName as defined by
{direction} One of
For each Binding Message Reference component in the {message references} property of a Binding Operation component, the {message label} property MUST be unique. That is, the same message cannot be bound twice within the same operation.
The XML representation for a Binding Message Reference component
is an
A [local name] of
A [namespace name] of
One or more
An OPTIONAL
If the {message exchange pattern} of the
Interface Operation component being bound has only
one message with a given value for {direction}, then
the
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
The
A [local name] of
A [namespace name] which has no value.
The type of the
Binding Message Reference extension elements are used
to provide information specific to a particular
message in an operation. The semantics of such
The mapping between the properties of the Binding Message
Reference component (see
Property | Mapping |
---|---|
{message label} | The actual value of
the |
{direction} | If the [local name] of
the |
A Service component describes a set of endpoints (see
Services are named constructs and can be referred to by QName
(see
The properties of the Service component are as follows:
{name} An NCName as defined by
{target namespace} A namespace name, as defined
in
{interface} An Interface component.
{endpoints} A set of Endpoint components.
For each Service component in the {services} property of a definitions container, the combination of {name} and {target namespace} properties MUST be unique.
The XML representation for a Service component
is an
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
A REQUIRED
Zero or more namespace qualified
One or more
An OPTIONAL
One or more
One or more
Zero or more namespace-qualified
Note that the XML Schema
See the primer
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Service component (see
Property | Mapping |
---|---|
{name} | The actual value of the |
{target namespace} |
The actual value of the |
{interface} |
|
{endpoints} |
The Endpoint components corresponding to the |
An Endpoint component defines the particulars of a specific endpoint at which a given service is available.
Endpoint components are local to a given Service component; they cannot be referred to by QName.
The properties of the Endpoint component are as follows:
{name} An NCName as defined by
{binding} A named Binding component.
For each Endpoint component in the {endpoints} property of a
Service component, the {binding} property (see
For each Endpoint component in the {endpoints} property of a Service component, the {name} property MUST be unique.
The XML representation for a Endpoint component
is an
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
A REQUIRED
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
The
The
A [local name] of
A [namespace name] which has no value.
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
Endpoint extension elements are used to provide information
specific to a particular endpoint in a server. The semantics of such
The mapping between the properties of the Endpoint component (see
Property | Mapping |
---|---|
{name} | The actual value of the |
{binding} |
The Binding component resolved to by the actual value of
the |
Two components of the same type are considered equivalent if, for each property, the value in the first component is the same as the value in the second component.
With respect to top-level components (Interfaces, Bindings and Services) this effectively translates to name-based equivalence given the constraints on names. That is, given two top-level components of the same type, if their {name} properties have the same value and their {target namespace} properties have the same values then the two components are in fact, the same component.
This specification defines three symbol spaces, one for each top-level component type (Interface, Binding and Service).
Within a symbol space, all qualified names (that is, the combination of {name} and {target namespace} properties) are unique. Between symbol spaces, the combination of these two properties need not be unique. Thus it is perfectly coherent to have, for example, a binding and an interface that have the same name.
When XML Schema is being used as one of the type systems for a
WSDL description, then six other symbol spaces also exist, one for
each of: global element declarations, global attribute
declarations, named model groups, named attribute groups, type
definitions and key constraints, as defined by
In its serialized form WSDL makes significant use of references between components. Such references are made using the Qualified Name, or QName, of the component being referred to. QNames are a tuple, consisting of two parts; a namespace name and a local name. For example, in the case of an Interface component, the namespace name is represented by the {namespace name} property and the local name is represented by the {name} property.
QName references are resolved by looking in the appropriate
property of the Definitions component. For example, to resolve a
QName of an interface (as referred to by the
If the appropriate property of the Definitions component does not contain a component with the required QName then the reference is a broken reference. It is an error for a Definitions component to have such broken references.
This specification uses absolute URIs to identify several
components (for example, features and properties) and components
characteristics (for example, operation message exchange patterns
and styles). When such absolute URIs are being compared to determine
equivalency (see
At the abstract level, the {element declarations} property of
Support for the W3C XML Schema Description Language
The schema components contained in the {element declarations}
properties of
The
A [local name] of
A [namespace name] of
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more
Other namespace qualified
XML Schema MAY be used as the schema language via import or
embedding. Each method defines a different
A WSDL description MUST NOT refer to XML Schema components in a given
namespace unless an
Importing an XML Schema uses the syntax and semantics of the
A child
A [local name] of
A [namespace name] of
One or two
A REQUIRED
An OPTIONAL
The
The
A [local name] of namespace
A [namespace name] which has no value.
The type of the
The
A [local name] of schemaLocation.
A [namespace name] which has no value.
The type of the
Embedding an XML schema uses the existing top-level
The schema components defined in the embedded schema are available to
WSDL for reference by QName (see
Similarly, components defined in an embedded XML schema are NOT automatically
made available to a WSDL description that imported (using
Inside an embedded XML schema, the
The
A [local name] of schema.
A [namespace name] of
A REQUIRED
Additional OPTIONAL
Zero or more child
The
A [local name] of targetNamespace.
A [namespace name] which has no value.
The type of the
Whether embedded or imported, the element declarations present in a schema may be referenced from a Message Reference or Interface Fault component.
A named, global
Since it is unreasonable to expect that a single schema language can
be used to describe all possible Message Reference and Fault
component contents and their constraints, WSDL allows alternate schema
languages to be specified via extensibility elements. An
extensibility
A specification of extension syntax
for an alternative schema language MUST include the declaration of an
See
This specification provides two mechanisms, described in this section, for modularizing WSDL descriptions. These mechanisms help to make WSDL descriptions clearer by allowing separation of the various components of a description. Such separation could be performed according to the level of abstraction of a given set of components, or according to the namespace affiliation required of a given set of components or according to some other grouping such as application applicability.
Both mechanisms work at the level of WSDL components and NOT at the level of XML Information Sets or XML 1.0 serializations.
The WSDL
The WSDL
A mutual include is direct inclusion by one WSDL document of another WSDL document which includes the first. A circular include achieves the same effect with greater indirection (WSDL A includes WSDL B includes WSDL A, for instance). Multiple inclusion of a single WSDL document resolves to a single set of components. Mutual, multiple, and circular includes are explicitly permitted, and do not represent multiple redefinitions of the same components. Multiple inclusion of a single WSDL document has the same meaning as including it only once. Processors are encouraged to keep track of the source of component definitions, so that multiple, mutual, and circular includes do not require establishing identity on a component-by-component basis.
The
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
Zero or more
An optional
Zero or more namespace-qualified
The
A [local name] of
A [namespace name] which has no value.
A
If the URI indicated by
The actual value of the
The WSDL
The WSDL
Using the
This specification DOES NOT preclude repeating the
Furthermore, this specification DOES NOT require the
The
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
Zero or more
An optional
Zero or more namespace-qualified
The
A [local name] of
A [namespace name] which has no value.
The
The
A [local name] of
A [namespace name] which has no value.
The
The
WSDL uses the optional
The
A [local name] of
A [namespace name] of
Zero or more
Zero or more child
Zero or more
The schema for WSDL has a two-part extensibility model based on namespace-qualified elements and attributes. The extension is identified by the qname consisting of its namespace URI and its element name. The meaning of the extension SHOULD be defined (directly or indirectly) in a document that is available at its namespace URI.
WSDL allows extensions to be defined in terms of
It is expected that extensions will want to add to the
existing properties of components in the component model. The
specification for an extension
The WSDL schema also defines a base type for use by extensibility
elements.
Extensibility elements are commonly used to specify some technology-specific binding. They allow innovation in the area of network and message protocols without having to revise the base WSDL specification. WSDL recommends that specifications defining such protocols also define any necessary WSDL extensions used to describe those protocols or formats.
Extension elements can be marked as mandatory by annotating them
with a
An extension that is NOT marked as mandatory MUST NOT invalidate the meaning of any part of the WSDL document. Thus, a NON-mandatory extension merely provides additional description of capabilities of the service. Furthermore, any extension that is NOT marked as mandatory and which is NOT understood, MUST be ignored. Any NOT understood extension attributes MUST be ignored as this specification does not provide a mechanism to mark extension attributes as being required.
A mandatory extension is considered mandatory because it has the ability to change the meaning of the element to which it is attached. Thus, the meaning of the element may not be fully understood without understanding the attached extension. A NON-mandatory extension, on the other hand, can be safely ignored without danger of misunderstanding the rest of the WSDL document.
WSDL provides a global
A [local name] of
A [namespace name] of
A [specified] property with a value of
The type of the
WSDL allows qualified
WSDL does not provide a mechanism for marking extension
As indicated above, it is expected that the presence of extensibility elements and attributes will result in additional properties appearing in the component model.
The presence of an optional extensibility element or attribute MAY therefore augment the semantics of a WSDL document in ways that do not invalidate the existing semantics. However, the presence of a mandatory extensibility element MAY alter the semantics of a WSDL document in ways that invalidate the existing semantics.
Authors of extensibility elements should avoid altering the existing semantics in ways that are likely to confuse users.
As an XML vocabulary, WSDL documents or fragments or references
to WSDL components (via QNames) MAY appear within other XML
documents. In such scenarios it could be necessary to provide some
hints on where additional WSDL information for a given namespace can
be found in order to help with QName resolution
This specification defines a global attribute,
WSDL provides a global
A [local name] of
A [namespace name] of
The type of the
An
This specification conforms to the
This section defines a class of conformant WSDL processors that are intended to act on behalf of a party that wishes to make use of a Web service (i.e., the requester entity or requester agent), rather than the party that implements the Web service (i.e., the provider entity or provider agent).
An extension element is said to be
A conformant WSDL processor MUST adhere to the following rules:
Except as noted below for mandatory extensions, a conformant WSDL processor MUST accept any legal WSDL document as defined by this specification.
A conformant WSDL processor MUST fault if a portion of a WSDL document is illegal according to this specification and the WSDL processor attempts to process that portion.
A conformant WSDL processor MUST support at least XML Schema as a type system language.
A conformant WSDL processor MUST fail if it processes an element containing a wsdl:include statement having a URI that is not dereferenceable to a legal WSDL document.
If a mandatory extension (i.e., a mandatory element, feature or property) is processed, a conformant WSDL processor MUST either agree to fully abide by all the rules and semantics signaled by that extension, or immediately cease processing (fault). In particular, if the WSDL processor does not recognize the extension, it MUST fault. If the WSDL processor recognizes the extension, and determines that the extension in question is incompatible with any other aspect of the document (including other required extensions), it MUST fault.
A conformant WSDL processor MAY safely ignore a NON-mandatory extension that it does not recognize or that it does not choose to implement.
This appendix defines the
application
wsdl+xml
none
This parameter has identical semantics to the charset parameter
of the
Identical to those of
See section
There are no known interoperability issues.
This document and
No known applications currently use this media type.
WSDL documents are not required or expected to be stored as files.
Either a syntax identical to that of
As specified in
TEXT
@@@ <@@@@>
COMMON
The WSDL 2.0 specification set is a work product of the World Wide
Web Consortium's
This media type uses the
This document is the work of the
Members of the Working Group are (at the time of writing, and by alphabetical order): Mike Ballantyne (Electronic Data Systems), David Booth (W3C), Allen Brookes (Rogue Wave Softwave), Roberto Chinnici (Sun Microsystems), Glen Daniels (Sonic Software), Alan Davies (SeeBeyond), Mike Davoren (W. W. Grainger), Paul Downey (British Telecommunications), Youenn Fablet (Canon), Yaron Goland (BEA), Martin Gudgin (Microsoft Corporation), Hugo Haas (W3C), Hao He (The Thomson Corporation), Tom Jordahl (Macromedia), Jacek Kopecky (Systinet), Dan Kulp (IONA Technologies), Sandeep Kumar (Cisco Systems), Amelia Lewis (TIBCO Software, Inc.), Kevin Canyang Liu (SAP), Michael Mahan (Nokia), Jonathan Marsh (Microsoft Corporation), Mike McHugh (W. W. Grainger), Michael Mealling (Verisign), Ingor Melzer (DaimlerChrysler Research and Technology), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau (Canon), David Orchard (BEA), Bijan Parsia (University of Maryland), Arthur Ryman (IBM), Waqar Sadiq (Electronic Data Systems), Adi Sakala (IONA Technologies), Jeffrey Schlimmer (Microsoft Corporation), Igor Sedukhin (Computer Associates), Sandra Swearingen (U.S. Department of Defense, U.S. Air Force), Bryan Thompson (Hicks & Associates), Jerry Thrasher (Lexmark), William Vambenepe (Hewlett-Packard Company), Asir Vedamuthu (webMethods, Inc.), Sanjiva Weerawarana (IBM), Ümit Yalçınalp (Oracle Corporation), Prasad Yendluri (webMethods, Inc.).
Previous members were: Lily Liu (webMethods, Inc.), Don Wright (Lexmark), Joyce Yang (Oracle Corporation), Daniel Schutzer (Citigroup), Dave Solo (Citigroup), Stefano Pogliani (Sun Microsystems), William Stumbo (Xerox), Stephen White (SeeBeyond), Barbara Zengler (DaimlerChrysler Research and Technology), Tim Finin (University of Maryland), Laurent De Teneuille (L'Echangeur), Johan Pauhlsson (L'Echangeur), Mark Jones (AT&T), Steve Lind (AT&T), Philippe Le Hégaret (W3C), Jim Hendler (University of Maryland), Dietmar Gaertner (Software AG), Michael Champion (Software AG), Don Mullen (TIBCO Software, Inc.), Steve Graham (Global Grid Forum), Steve Tuecke (Global Grid Forum).
The people who have contributed to
This appendix provides a syntax for URI references for named components found in a WSDL document. This includes the top level components: interface, binding and service and the subordinate components: operation, fault, and endpoint. The URI references are easy to understand and compare, while imposing no burden on the WSDL author.
There are two main cases for WSDL URIs:
the URI of a WSDL document
the URI of a WSDL namespace
The URI of a WSDL document can be dereferenced to give a resource representation that contributes component definitions to a single WSDL namespace. If the media type is set to the WSDL media type, then the fragment identifiers can be used to identify the main components that are defined in the document.
However, in keeping with the recommendation in
The following fragment identifier syntax is compliant with the
The URI in a URI-reference for a WSDL component is the
{target namespace} property of either the component itself, in
the case of interfaces, bindings, and services, or the {target
namespace} property of an ancestor component. The URI provided
by the {target namespace} property is combined with a fragment
identifier, where the fragment identifier is constructed from
the {name} property of the component and the {name} properties
of its ancestors as a path according to
Construct | x | y | Fragment |
---|---|---|---|
interface | {name} property of interface | n/a | interface(x) |
operation | {name} property of operation | {name} property of parent interface | operation(y/x) |
fault | {name} property of fault | {name} property of parent interface | fault(y/x) |
binding | {name} property of binding | n/a | binding(x) |
service | {name} property of service | n/a | service(x) |
endpoint | {name} property of endpoint | {name} property of parent service | endpoint(y/x) |
Note that the above rules are defined in terms of component properties rather the XML Infoset representation of the component model.
WSDL has an open content model. It is therefore possible for an extension to define new components. The XPointer Framework scheme for components added by extensions is:
extension(extension-namespace, extension-specific-syntax)
where extension-namespace is the namespace that identifies the extension, e.g. for SOAP the namespace is http://www.w3.org/2003/06/wsdl/soap12, and extension-specific-syntax is defined by the extension. The owner of the extension must define any components contributed by the extension and a syntax for identifying them.
Consider the following WSDL located at http://example.org/TicketAgent.wsdl:
Its conceptual elements have the following URI-references:
This section will attempt to document some of the migration concerns of going from WSDL 1.1 to WSDL 2.0. We do not claim that all migration problems will be addressed here.
WSDL 1.1 supported operation overloading and WSDL 2.0 removes it. This section will provide some rationale for it and provide hints on how to work around some scenarios.
Port types have been renamed to interfaces. We now have interface inheritance.
Ports have been renamed to endpoints.
A DTD may be used as the schema language for WSDL. It may not be embedded;
it must be imported. A namespace must be assigned. DTD types appear
in the {element declarations} property of
The prefix, dtd, used throughout the following is mapped to the
namespace URI
The
A [local name] of import.
A [namespace name] of "http://www.example.org/dtd".
One or two
A REQUIRED
An OPTIONAL
The
A [local name] of namespace.
A [namespace name] which has no value.
The type of the
The WSDL author should ensure that a prefix is associated with the namespace at the proper scope (probably document scope).
The
A [local name] of location.
A [namespace name] which has no value.
The type of the
The
Note that this pattern does not attempt to make DTDs namespace-aware. It applies namespaces externally, in the import phase.
A RELAX NG schema may be used as the schema language for WSDL. It may be
embedded or imported; import is preferred. A namespace must be specified;
if an imported schema specifies one, then the [actual value] of the
Importing a RELAX NG schema uses the rng:include mechanism defined by RNG,
with restrictions on its syntax and semantics. A child
A [local name] of include.
A [namespace name] of "http://www.relaxng.org/ns/structure/1.0".
Two
A REQUIRED
An OPTIONAL
Additional
Note that WSDL restricts the
The
A [local name] of ns.
A [namespace name] which has no value.
The type of the
The
A [local name] of href.
A [namespace name] which has no value.
The type of the
Embedding an RNG schema uses the existing top-level
A [local name] of grammar.
A [namespace name] of "http://www.relaxng.org/ns/structure/1.0".
A REQUIRED
Additional
Child
The
A [local name] of ns.
A [namespace name] which has no value.
The type of the
Whether embedded or imported, the element definitions present in a schema may be referenced from a Message Reference or Interface Fault component.
A named rng:define definition MUST NOT be referenced from the Message Reference or Interface Fault components.
A named Relax NG element declaration MAY be referenced from a Message
Reference or Interface Fault component. The QName is constructed from
the namespace (
Date | Author | Description | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
20040323 | JJM | Commented out the (missing) property example. | ||||||||||||
20040322 | RRC | Added definition of wsdli:wsdlLocation attribute. | ||||||||||||
20040322 | JJM | Added faults to properties and features. | ||||||||||||
20040319 | JJM | Use lowercase "should" in notes. | ||||||||||||
20040319 | JJM | Comment out features at service level. Uniformize scope between features and properties. | ||||||||||||
20040318 | JJM | Moved normative notes into the main body of the document. | ||||||||||||
20040318 | JJM | Incorporated the property text from Glen. | ||||||||||||
20040318 | JJM | Addressed comments from Yuxiao Zhao. | ||||||||||||
20040318 | JJM | Updated the feature description, as per Glen and David Booth's suggestions. | ||||||||||||
20040317 | RRC | Removed redundant {styleDefault} property of the interface component. | ||||||||||||
20040317 | JJM | Include comments from Kevin. | ||||||||||||
20040315 | RRC | Added clarification on embedded XML schemas that refer to siblings. | ||||||||||||
20040315 | RRC | Updated RPC signature extension to use #in/#out/#inout/#return tokens. | ||||||||||||
20040315 | RRC | Added explanatory text to types and modularization sections per resolution of issue #102. | ||||||||||||
20040315 | SW | Change binding/{fault,operation}/@name to @ref | ||||||||||||
20040312 | RRC | Fixed appendix D to take the removal of wsdl:message into account. | ||||||||||||
20040312 | RRC | Added definition of wrpc:signature extension attribute. | ||||||||||||
20040311 | SW | Change fault stuff per decision to make faults first class in interfaces. | ||||||||||||
20040308 | SW | Renamed {message} property to {element} and @message to @element | ||||||||||||
20040305 | SW | Added {safety} property | ||||||||||||
20040227 | MJG | Merged in branch Issue143 containing resolution of issue 143 | ||||||||||||
20040227 | SW | Dropped {type definitions} property from definitions; leftover from <message> days. | ||||||||||||
20040226 | SW | Working thru various edtodo items. | ||||||||||||
20040106 | JS | Per 18 Dec 2003 telecon decision, added text re: circular includes. | ||||||||||||
20031204 | JS | Per 4 Dec 2003 telecon decision, removed redundant binding/operation/{infault, outfault}/@messageReference. | ||||||||||||
20031105 | JS | Added point to attributes task force recommendation accepted by the working group. | ||||||||||||
20031104 | JS | Mapping to component model for {message} of Fault Reference
component indicated that |
||||||||||||
20031104 | JS | Renamed interface /operation /{input,output} /@body to ./@message and interface /operation /{infault,outfault} /@details to ./@message per 4 Nov face-to-face decision. | ||||||||||||
20031104 | JS | Made interface /operation /{input,output,infault,outfault} /@messageReference optional per 4 Nov face-to-face decision. | ||||||||||||
20031104 | JS | Removed interface/operation/{input,output}/@header per 4 Nov face-to-face decision. | ||||||||||||
20031102 | SW | Updated fault reference components to indicate that if operation's MEP uses MTF then the fault is in the opposite direction as the referenced message and if it use FRM then its in the same direction. Per 10/30 telecon decision. | ||||||||||||
20031102 | SW | Updated operation styles terminology per message #57 of Oct. and the RPC style rules per message #58 of Oct. per decision on 10/30 telecon to consider those status quo. | ||||||||||||
20031102 | SW | Clarified wording in operation styles discussion to better explain the use of the {style} attribute. | ||||||||||||
20031102 | SW | Clarified wording in XML <-> component model mapping section for message reference components to say that {body} and {headers} may not have a value. | ||||||||||||
20031102 | SW | Made interface/operation/(input|output)/@messageReference REQUIRED per 10/30 telecon decision. | ||||||||||||
20031028 | SW | Renamed to wsdl20.xml and updated contents. | ||||||||||||
20031028 | SW | Updated bindings. | ||||||||||||
20031025 | SW | Updated faults. | ||||||||||||
20031013 | JJM | Moved appendix C to a separate document, as per 24 Sep 2003 meeting in Palo Alto, CA. | ||||||||||||
20031003 | SW | Softened <documentation> wording to allow machine processable documentation. | ||||||||||||
20031002 | SW | Changed binding/operation/@name to QName per edtodo. | ||||||||||||
20030930 | SW | Added placeholders for set-attr/get-attr operation styles. | ||||||||||||
20030929 | SW | Inserted Glen Daniels' feature text. | ||||||||||||
20030919 | RRC | Removed import facility for chameleon schemas and added a description of a workaround. | ||||||||||||
20030918 | JJM | Changed message pattern to message exchange pattern, as per WG resolution on 18 Sep. 2003 | ||||||||||||
20030916 | RRC | Added editorial note for the missing RPC encoding style. | ||||||||||||
20030915 | RRC | Yet more updates for REQUIRED, OPTIONAL; updated section 3 to reflect the removal of "wsdl:message". | ||||||||||||
20030911 | RRC | More updates for REQUIRED, OPTIONAL; removed diff markup; fixed example C.4. | ||||||||||||
20030911 | RRC | Renamed message reference "name" attribute and property to "messageReference"; fixed incorrect reference to "fault" element in the binding operation section. | ||||||||||||
20030910 | SW | Fixed message references and added proper use of REQUIRED etc. for the part I've gone through so far. | ||||||||||||
20030910 | SW | Updating spec; fixed up interface operation component more. | ||||||||||||
20030808 | JCS | Fixed errors found by IBM\Arthur. | ||||||||||||
20030804 | JCS | Removed Message component per 30 July-1 Aug meeting. | ||||||||||||
20030803 | JCS | Replaced substitution groups with xs:any namespace='##other' per 3 July, 17 July, and 24 July telecons. | ||||||||||||
20030801 | JCS | Made binding/@interface optional per 31 July meeting. | ||||||||||||
20030724 | JCS | Remove @targetResource per 17 July 2003 telecon. | ||||||||||||
20030612 | JJM | Incorporate revised targetResource definition, as per 12 June 2003 telcon. | ||||||||||||
20030606 | JJM | Refer to the two graphics by ID. Indicate pseudo-schemas are not normative. | ||||||||||||
20030604 | JJM | Fixed figures so they don't appear as tables. Fixed markup so it validates. | ||||||||||||
20030603 | JCS | Plugged in jmarsh auto-generated schema outlines | ||||||||||||
20030529 | MJG | Fixed various issues with the XmlRep portions of the spec | ||||||||||||
20030527 | MJG | Added text to |
||||||||||||
20030523 | JJM | Added pseudo-syntax to all but Type and Modularizing sections. | ||||||||||||
20030523 | JJM | Added the "interface" and "targetResource" attribute on <service>. | ||||||||||||
20030523 | JJM | Fixed miscellaneous typos (semi-colon instead of colon, space after parenthesis, etc.). | ||||||||||||
20030523 | JJM | Rewrote the service-resource text and merge it with the introduction. | ||||||||||||
20030522 | JCS | s/set of parts/list of parts/. | ||||||||||||
20030514 | JJM | Updated the service-resource figure, and split the diagram into two. | ||||||||||||
20030512 | JJM | Added service-resource drawing and description. | ||||||||||||
20030512 | JJM | Added syntax summary for the Interface component. | ||||||||||||
20030428 | MJG | Various edits to |
||||||||||||
20030428 | MJG | Added text to |
||||||||||||
20030411 | JJM | Allowed features and properties at the interface, interface operation, binding and binding operation levels, as agreed at the Boston f2f http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0019.html. | ||||||||||||
20030411 | JJM | Incorporate features and properties' text from separate document and merged change logs | ||||||||||||
20030313 | MJG | Changed title to include 'part 1' | ||||||||||||
20030313 | MJG | Changed port to endpoint | ||||||||||||
20030313 | MJG | Changed type to interface in binding | ||||||||||||
20030313 | MJG | Changed mep to pattern and message exchange pattern to message pattern | ||||||||||||
20030313 | MJG | Added text to |
||||||||||||
20030313 | MJG | Changed portType to interface | ||||||||||||
20030407 | JJM | Refined and corrected the definitions for features and properties. | ||||||||||||
20030304 | JJM | Filled in blank description of Feature and Property component. | ||||||||||||
20030303 | MJG | Skeleton Feature and Property components | ||||||||||||
20030305 | MJG | Merged ComponentModelForMEPs branch (1.46.2.5) into main
branch (1.54). Below is change log from the branch:
|
||||||||||||
20030228 | MJG | Updated |
||||||||||||
20030228 | MJG | Updated |
||||||||||||
20030228 | MJG | Updated |
||||||||||||
20030217 | MJG | Minor edits to wording in |
||||||||||||
20030213 | MJG | Added xlink nsdecl to spec element | ||||||||||||
20030213 | MJG | Incorporated text from dbooths proposal on semantics, per decision 20021031 | ||||||||||||
20030213 | MJG | Merged operationnames branch (1.37.2.3) into main
branch (1.46). Below is the change log
from the branch.
|
||||||||||||
20030213 | MJG | Change name of {message exchange pattern} back to {variety} to consolidate changes due to MEP proposal | ||||||||||||
20030206 | MJG | Updated Appendix A to refer to Appendix C | ||||||||||||
20030204 | MJG | Tidied up appendix C | ||||||||||||
20030203 | MJG | Incorporated resolution to R120 | ||||||||||||
20030124 | MJG | Fixed error in |
||||||||||||
20030123 | JJM | Change name of {variety} property to {message exchange pattern} | ||||||||||||
20030130 | MJG | Updated binding section to match changes to port type section WRT operation names | ||||||||||||
20030130 | MJG | Added best practice note on operation names and target
namespaces to |
||||||||||||
20030122 | MJG | Started work on making operations have unique names | ||||||||||||
20030122 | MJG | Added some <emph>, <el>, <att>, &AII;, &EII;, <el> markup | ||||||||||||
20030120 | MJG | Incorporated Relax NG section from Amy's types proposal | ||||||||||||
20030120 | MJG | Incorporated DTD section from Amy's types proposal | ||||||||||||
2003020 | MJG | Incorporated Amy's types proposal except annexes | ||||||||||||
20030118 | MJG | Made some changes related to extensibility | ||||||||||||
20030118 | MJG | Amended content model for operation to disallow fault element children in the input-only and output-only cases | ||||||||||||
20030118 | MJG | Removed {extension} properties from Binding components and Port components. Added text relating to how extension elements are expected to annotate the component model. | ||||||||||||
20030117 | MJG | Made further edits related to extensibility model now using substitution groups | ||||||||||||
20030117 | MJG | Added initial draft of section on QName resolution | ||||||||||||
20030117 | MJG | Reworked section on extensibility | ||||||||||||
20030116 | MJG | Added text regarding multiple operations with the same {name} in a single port type | ||||||||||||
20030116 | MJG | Added section on symbol spaces | ||||||||||||
20030116 | MJG | Removed various ednotes | ||||||||||||
20030116 | MJG | Added section on component equivalence | ||||||||||||
20030116 | MJG | More work on include and import | ||||||||||||
20021201 | MJG | Did some work on wsdl:include | ||||||||||||
20021127 | MJG | Added placeholder for wsdl:include | ||||||||||||
20021127 | MJG | Cleaned up language concerning |
||||||||||||
20021127 | MJG | changed the language regarding extensibility elements in
|
||||||||||||
20021127 | MJG | Moved all issues into issues document ( ../issues/wsd-issues.xml ) | ||||||||||||
20021127 | MJG | Removed name attribute from definitions element | ||||||||||||
20021127 | MJG | Removed 'pseudo-schema' | ||||||||||||
20021121 | JJM | Updated media type draft appendix ednote to match minutes. | ||||||||||||
20021111 | SW | Added appendix to record migration issues. | ||||||||||||
20021107 | JJM | Incorporated and started adapting SOAP's media type draft appendix. | ||||||||||||
20021010 | MJG | Added port type extensions, removed service type. | ||||||||||||
20020910 | MJG | Removed parameterOrder from spec, as decided at September 2002 FTF | ||||||||||||
20020908 | MJG | Updated parameterOrder description, fixed some spelling errors and other types. Added ednote to discussion of message parts | ||||||||||||
20020715 | MJG | AM Rewrite | ||||||||||||
20020627 | JJM | Changed a few remaining <emph> to either <att> or <el>, depending on context. | ||||||||||||
20020627 | SW | Converted portType stuff to be infoset based and improved doc structure more. | ||||||||||||
20020627 | SW | Converted message stuff to be infoset based and improved doc structure more. | ||||||||||||
20020625 | SW | Mods to take into account JJM comments. | ||||||||||||
20020624 | JJM | Fixed spec so markup validates. | ||||||||||||
20020624 | JJM | Upgraded the stylesheet and DTD | ||||||||||||
20020624 | JJM | Added sections for references and change log. | ||||||||||||
20020624 | JJM | Removed Jeffrey from authors :-( Added Gudge :-) | ||||||||||||
20020620 | SW | Started adding abstract model | ||||||||||||
20020406 | SW | Created document from WSDL 1.1 |