This document describes the Web Services Description Language Version 2.0 (WSDL 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 the conformance criteria for documents in this language.
This is the
This Working Draft addresses all the comments received during
the second Last Call review period on the WSDL 2.0
drafts. The detailed disposition of the comments received
can be found in the
The Working Group plans to submit
this specification for consideration as a
Two interoperable implementations of all the features, both mandatory and optional, of the specifications have been produced.
The Working Group releases a test suite along with an
The sections
Implementers are encouraged to
Issues about this document are recorded in the
Publication as a Candidate Recommendation 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.
This document has been produced under the
Last Modified: $Date: 2006/01/05 19:39:13 $
Web Services Description Language Version 2.0 (WSDL 2.0) provides a model and an XML format for describing Web services. WSDL 2.0 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 the conformance criteria for documents in this language.
The
WSDL 2.0 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 to separate independent design concerns.
At an abstract level, WSDL 2.0 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
An
The definition of the WSDL 2.0 language is based on the XML Information
Set
An XML 1.0 document that is valid with respect to the WSDL 2.0 XML Schema and that maps to a valid WSDL 2.0 Component Model is conformant to the WSDL 2.0 specification.
A WSDL 2.0 service description indicates how potential clients are
intended to interact with the described service. It represents an
assertion that the described service fully implements and conforms to
what the WSDL 2.0 document describes. For example, as further
explained in section
A WSDL 2.0 interface describes potential interaction with a service--not required interaction. The declaration of an operation in a WSDL 2.0 interface is not an assertion that the interaction described by the operation must occur. Rather it is an assertion that if such an interaction is (somehow) initiated, then the declared operation describes how that interaction is intended to occur.
All parts of this specification are normative, with the EXCEPTION of notes, pseudo-schemas, examples, and sections explicitly marked as “Non-Normative”.
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
Namespace names of the general form:
represent application or
context-dependent URIs
This specification uses the XML Schema type
For interoperability, WSDL authors are advised to avoid the US-ASCII characters: "<", ">", '"', space,
"{", "}", "|", "\", "^", and "`", which are allowed by the
This specification uses predefined namespace prefixes throughout;
they are given in the following list. Note that the choice of any
namespace prefix is arbitrary and not semantically significant (see
Defined by this specification.
Defined by this specification
Defined by this specification
Defined by WSDL 2.0: Adjuncts
Defined by WSDL 2.0: Adjuncts
Defined by WSDL 2.0: Adjuncts
Defined in the W3C XML Schema
specification
Defined in the W3C XML Schema
specification
This section describes the terms and concepts introduced in Part 1 of the WSDL Version 2.0 specification (this document).
As in
An XML schema that is defined in the
This specification refers to properties in the XML Information Set
This specification defines and refers to properties in the WSDL 2.0 Component Model
This specification uses a consistent naming convention for component model properties that refer to components. If a property refers to a required or optional component, then the property name is the same as the component name. If a property refers to a set of components, then the property name is the pluralized form of the component name.
Z Notation
Since Z Notation is not widely known, it is not included the normative
version of this specification. However, it is included in a
The Z Notation was used to improve the quality of the normative text that defines the Component Model, and to help ensure that the test suite covered all important rules implied by the Component Model. However, the Z Notation is non-normative, so any conflict between it and the normative text is an error in the Z Notation. Readers and implementors may nevertheless find the Z Notation useful in cases where the normative text is unclear.
There are two elements of Z Notation syntax that conflict with the notational conventions described in the preceding sections.
In Z Notation, square brackets are used to introduce basic sets, e.g.
Pseudo-schemas are provided for each component, before the description
of the component. They use BNF-style conventions for attributes and elements:
Assertions about WSDL 2.0 documents and components that are
not enforced by the normative XML schema for WSDL 2.0 are
marked in the
The assertions and their identifiers are
summarized in an Assertion Summary Appendix that is included
the
This section describes the conceptual model of WSDL 2.0 as a set of
components with attached properties, which collectively describe a Web
service. This model is called the
A WSDL 2.0 document, and its related documents, defines a set of components that together form an instance of a Component Model. This specification defines the structure and constraints on the components in a valid component model instance.
Let
The definition of
Components are typed collections of properties that correspond to
different aspects of Web services.
Each subsection herein describes a different type of
component, its defined properties, and its representation as an XML
Infoset
Let
The
When a component property is said to contain another component or a set of other components, the intended meaning is that the component property contains a reference to another component or a set of references to other components. Every component contains an unique identifier that is used to express references.
Let
The
Every component has an identifier which uniquely identifies it within a component model instance.
Let
Let
The
All component properties that contain an
Let
The
A component model is a set of uniquely identified components that satisfy a set of validity constraints which are described in the following sections.
Let
Let
Let
No two components have the same identifier.
An identifier is valid if it is the identifier of a component in the component model.
Let
In order to express the additional contraints on the component model, it is convenient to define the subsets of components of each type and their corresponding subsets of identifiers.
Let
Let
Let
Let
Let
Let
The definition of
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
Let
The definition of
Many of the component types in the
component model have a set of
Let
The base properties of a component are valid when the Features and Properties properties are valid:
Let
Nested components have an additional
Let
The properties of a nested base component are valid
when the base properties are valid and the
Let
Properties are unordered and unique with respect to the component they are associated with. Individual properties' definitions may constrain their content (e.g., to a typed value, another component, or a set of typed values or components), and components may require the presence of a property to be considered conformant. Such properties are marked as REQUIRED, whereas those that are not required to be present are marked as OPTIONAL. By convention, when specifying the mapping rules from the XML Infoset representation of a component to the component itself, an optional property that is absent in the component in question is described as being “empty”. Unless otherwise specified, when a property is identified as being a collection (a set or a list), its value may be a 0-element (empty) collection. In order to simplify the presentation of the rules that deal with sets of components, for all OPTIONAL properties whose type is a set, the absence of such a property from a component MUST be treated as semantically equivalent to the presence of a property with the same name and whose value is the empty set. In other words, every OPTIONAL set-valued property MUST be assumed to have the empty set as its default value, to be used in case the property is absent.
An OPTIONAL simple property type is treated as a set-valued type that contains at most one member. If the property is absent then its value is the empty set. If the property is present then its value is the singleton set that contains the actual value of the property.
Let
An optional value of type
For example,
The definition of
Component definitions are serializable in XML 1.0 format but are
independent of any particular serialization of the component model.
Component definitions use a subset
(see
In addition to the direct XML Infoset representation described here,
the component model allows components external to the Infoset through
the mechanisms described in
A component model can be extracted from a given XML Infoset which
conforms to the XML Schema for WSDL 2.0 by recursively mapping
Information Items to their identified components, starting with the
This document does not specify a means of producing an XML Infoset representation from a component model instance. In particular, there are in general many valid ways to modularize a given component model instance into one or more XML Infosets.
At the abstract level, the
WSDL 2.0 components are interfaces, bindings and services. Type system components are element declarations and type definitions.
Type system components describe the constraints on a
message's content. By default, these constraints are expressed
in terms of the
This specification does not define the behavior of a WSDL 2.0 document that uses multiple schema languages for describing type system components simultaneously.
Let
The detailed structure of
An
Let
Let
Let
Let
Each
Let
No two
A
Let
Let
Let
Let
Each
Let
No two
Let
Let
Let
The parent of a nested component in the component model MUST also be in the component model. No component is its own parent.
Let
Let
Let
The properties of the
Let
The component model contains a unique
Let
Let
The component model contains a unique
Each component refered to by the properties of the
Let
The
The
The
The
The
The set of top-level components contained in the
In addition to WSDL 2.0 components and type system
components, additional extension components MAY be added via
extensibility
WSDL 2.0 definitions are represented in XML by one or more WSDL 2.0
Information Sets (Infosets), that is one or more
The components directly defined or included within a
If a WSDL 2.0 document is split into multiple WSDL 2.0 documents
(which may be combined as needed via
The
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
Zero or more
Zero or more
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 from the XML Representation of the
| Property | Value |
|---|---|
|
The set of |
|
|
The set of |
|
|
The set of |
|
|
The set of |
|
|
The set of |
An
An interface can optionally extend one or more other interfaces.
Interfaces are named constructs and can be referred to by
QName (see
The properties of the
Let
Let
Let
Let
Each component referenced by an
Let
This Z schema introduces some additional notation.
The universal quantifier
Every
The
The
The
Let
No two
An
Let
The set of
The set of
The set of all extended interfaces that are available on an
Let
An
An
Let
The set of all
Let
An
The set of all
Let
An
Let
The XML representation for 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
Zero or more
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 from the XML Representation of
the
| Property | Value |
|---|---|
| The QName whose local name is actual value of the |
|
|
The set of |
|
|
The set of |
|
|
The set of |
|
|
The set of |
|
|
The set of |
Recall that, per
A fault is an event that occurs during the execution of a message exchange that disrupts the normal flow of messages.
A fault is typically raised when a party is unable to communicate an error condition inside the normal message flow, or a party wishes to terminate a message exchange. A fault message may be used to communicate out of band information such as the reason for the error, the origin of the fault, as well as other informal diagnostics such as a program stack trace.
An
The
Faults other than the ones described in the
The properties of the
Let
Each component referenced by an
Let
Every
The
Let
No two
Despite having a
Let
No two
Note that, due to the above rules, if two interfaces that
have the same value for the namespace name of their
For the above reason, it is considered good practice to
ensure, where necessary, that the local name of the
If a type system NOT based on the XML Infoset
Let
The XML representation for an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
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 mapping from the XML Representation of the
| Property | Value |
|---|---|
| The QName whose local name is the actual value of the |
|
| The |
|
|
The set of |
|
|
The set of |
|
|
The |
An
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
The properties of the
Let
Each component referenced by an
Let
Every
The
The
Let
No two
Despite having a
Let
No two
Note that, due to the above rules, if two interfaces that
have the same value for the namespace name of their
For the above reason, it is considered good practice to
ensure, where necessary, that the
More than one
An
Let
The set of
The set of
Let
This section describes some aspects of message exchange
patterns in more detail. Refer to the
A
Let
Let
A
Let
Let the predefined fault propation rulesets be as follows:
A
Let
Each message exchange pattern has at least one placeholder message.
Each placeholder message in a message exchange pattern is uniquely identified by its message label.
An operation style specifies additional information about an operation.
For example, an operation style may define structural constraints on the element
declarations of the interface message reference or interface fault components used by the
operation. This additional information in no way affects the messages and faults
exchanged with the service and it may therefore be safely ignored in that
context. However, the additional information may be used for other
purposes, for example, improved code generation. The
If the
Please refer to the
The XML representation for an
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
One or more
Zero or more
One or more
One or more
Zero or more
Zero or more
Zero or more
Zero or more
Zero or more
A
A
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 from the XML
Representation of the
| Property | Value |
|---|---|
| The QName whose local name is the actual value of the |
|
| The actual value of the |
|
|
The set of message references corresponding to
the |
|
|
The set of interface fault references corresponding to the
|
|
|
The set containing the IRIs in the actual
value of the |
|
|
The set of |
|
|
The set of |
|
|
The |
An
A message exchange pattern defines a set of placeholder
messages that participate in the pattern and assigns them unique
message labels within the pattern (e.g. 'In', 'Out'). The purpose
of an
The properties of the
Let
Let
Let
The message content model is
Each component referenced by an
Let
Every
The
Let
No two
If a type system not based upon the XML Infoset is in use (as considered
in
Let
The XML representation for an
A [local name] of
A [namespace name] of
Zero or more
An OPTIONAL
An OPTIONAL
Zero or more namespace qualified
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
A [local name] of
A [namespace name] which has no value.
The type of the
The mapping from the XML Representation of the interface message reference
Define the
Define the
Define the
| Property | Value |
|---|---|
| The effective message label. | |
| The message direction. | |
| If the
|
|
| If the |
|
|
The set of |
|
|
The set of |
|
|
The |
An
A message exchange pattern defines a set of placeholder
messages that participate in the pattern and assigns them unique
message labels within the pattern (e.g. 'In', 'Out'). The purpose
of an
The companion specification
The properties of the
Let
Each component referenced by a
Let
Every
The
Let
No two
An
Let
Every
Let
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
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 mapping from the XML Representation of the message reference
Define the
Define the
Define the
Define the
| Property | Value |
|---|---|
|
The
|
|
| The effective message label. | |
| The fault direction. | |
|
The set of |
|
|
The set of |
|
|
The |
A
WSDL 2.0's
The properties of the
Let
The parent of a
Let
Let
No two
Let
The set of features which are required or available for a given component consists of the combined set of ALL feature declarations applicable to that component. A feature is applicable to a component if:
it is asserted directly within that component, or
it is asserted in a containing component, or
it is asserted in a component referred to by the current component.
Many of the component types in the component model contain a
Let
The in-scope features for a component always include the declared features for that component.
The
Let
Each
This component MUST be the parent of the
Following these rules, the set of features applicable at each component are as follows:
If a given feature is asserted at multiple locations, then the value of that feature at a particular component is determined by the conjunction of all the constraints implied by its asserted values. If a feature is not required then it may or may not be engaged, but if a feature is required then it must be engaged. Therefore, the conjunction of a required value and a non-required value is a required value. A composed feature is required if and only if at least one of its asserted values is required. This rule may be summarized as "true trumps".
In the following example, the
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
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 mapping from the XML Representation of
the
| Property | Value |
|---|---|
| The actual value of the |
|
|
The actual value of the |
|
|
The component corresponding to the
|
A “property” in the Features and Properties architecture represents a named runtime value which affects the behavior of some aspect of a Web service interaction, much like an environment variable. For example, a reliable messaging SOAP module may specify a property to control the number of retries in the case of network failure. WSDL 2.0 documents may specify the value constraints for these properties by referring to a Schema type, or by specifying a particular value. Properties, and hence property values, can be shared amongst features/bindings/modules, and are named with IRIs precisely to allow this type of sharing.
The properties of the
Let
A value constraint is either a
Let
Let
The value is constrained to be an explicitly given value exactly when
the
Each component referenced by a
Let
If the value constraint of a
The parent of each
Let
No two
If a type system not based upon the XML Infoset is in use (as considered
in
Let
At runtime, the behavior 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 (IRIs) to constraints. Each property IRI MAY therefore be associated with AT MOST one property constraint for a given interaction.
The set of properties which are required or available for a given component consists of the combined set of ALL property declarations applicable to that component. A property is applicable to a component if:
it is asserted directly within that component, or
it is asserted in a containing component, or
it is asserted in a component referred to by the current component.
Many of the component types in the component model contain a
Let
The in-scope properties for a component always include the declared properties for that component.
The
Let
Each
This component MUST be the parent of the
Following these rules, the set of properties applicable at each component are as follows:
Note that, in the text above, “property constraint”
(or, simply, “constraint”) is used to mean EITHER a
If a given Property is asserted at multiple locations,
then the value of that Property at a particular component
is determined by the conjunction of all the constraints of its in-scope
The reason that we phrase the requirement for a non-empty intersection as SHOULD rather than MUST, is that in general, it may be computationally difficult to determine by inspection of the type definitions that the intersection of two or more value sets is empty. Therefore, it is not a strict validity requirement that the intersection of the value sets be non-empty. An empty intersection will always result in failure of the service at run-time.
However, it is in general feasible to test specified values for either equality
or membership in value sets.
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
Zero or more
Zero or more
One OPTIONAL
A
A
Zero or more namespace-qualified
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 from the XML Representation of
the
| Property | Value |
|---|---|
| The actual value of the |
|
| If the
|
|
| The value of the [children] property of
the |
|
|
The component corresponding to the
|
A
If a
Conversely, a
No concrete binding details are given in this
specification. The companion specification,
A
Bindings are named constructs and can be referred to by
QName (see
The properties of the
Let
If no
Each component referenced by a
Let
Every
The
The
The
For each
Let
No two
A
Let
The set of
The set of
Let
The XML representation for a
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
An OPTIONAL
An REQUIRED
Zero or more namespace qualified
Zero or more
Zero or more
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
Binding extension elements are used to provide
information specific to a particular binding. The semantics
of such
The mapping from the XML
Representation of the
| Property | Value |
|---|---|
| The QName whose local name is the actual value of the |
|
|
The |
|
|
The actual value of the |
|
| The set of
|
|
| The set of |
|
| The set of |
|
| The set of |
A
Note that the fault does not occur by itself - it occurs as
part of a message exchange as defined by an
The properties of the
Let
Each component referenced by a
Let
Every
The
For each
Let
No two
A
Let
Each
Let
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
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 Fault extension elements are used to provide
information specific to a particular fault in a
binding. The semantics of such
The mapping from the
XML Representation of the
| Property | Value |
|---|---|
| The |
|
|
The set of |
|
|
The set of |
|
|
The |
The
The properties of the
Let
Each component referenced by a
Let
Every
The
The
The
For each
Let
No two
A
Let
The set of
The set of
A
Let
Each
Let
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
Zero or more
Zero or more
Zero or more
Zero or more
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 from the XML Representation of the
| Property | Value |
|---|---|
|
|
The
|
|
The set of
|
|
|
The set of
|
|
|
The set of
|
|
|
The set of
|
|
|
The
|
A
The properties of the
Let
Each component referenced by a
Let
Every
The
For each
Let
No two
The
Let
For each
Let
The XML representation for a
A [local name] of
A [namespace name] of
Zero or more
An OPTIONAL
Zero or more namespace qualified
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 Message Reference extension elements are used
to provide information specific to a particular
message in an operation. The semantics of such
The mapping from the XML
Representation of the
Define the
Define the
Define the
| Property | Value |
|---|---|
|
|
The |
| {features} |
The set of
|
| {properties} |
The set of
|
| {parent} |
The
|
A
The properties of the
Let
Each component referenced by a
Let
Every
The
For each
Let
No two
The
Let
For each
Let
The XML representation for a
A [local name] of
A [namespace name] of
One or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
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
The
A [local name] of
A [namespace name] which has no value.
The type of the
Binding Fault Reference extension elements are used
to provide information specific to a particular
fault in an operation. The semantics of such
The mapping from the XML
Representation of the
Define the
Define the
Define the
Define the
There MUST be an
| Property | Value |
|---|---|
|
|
The |
| {features} |
The set of
|
| {properties} |
The set of
|
| {parent} |
The
|
A
Services are named constructs and can be referred to by QName
(see
The properties of the
Let
Each component referenced by a
Let
Every
The
The
For each
Let
No two
A
Let
The set of
Let
The XML representation for a
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
A REQUIRED
Zero or more namespace qualified
One or more
Zero or more
One or more
One 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 mapping from the XML Representation of
the
| Property | Value |
|---|---|
| The QName whose local name is the actual value of the |
|
|
|
|
|
The |
|
|
The set of |
|
|
The set of |
An
The
The properties of the
Let
Each component referenced by a
Let
Every
The
The
The
For each
Let
No two
For each
Let
The
Let
The XML representation for a
A [local name] of
A [namespace name] of
Two or more
A REQUIRED
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
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
Endpoint extension elements are used to provide information
specific to a particular endpoint in a server. The semantics of such
The mapping from the XML Representation of
the
| Property | Value |
|---|---|
|
The actual value of the
|
|
|
The
|
|
|
The actual value of the
|
|
|
The set of
|
|
|
The set of
|
|
|
The
|
The XML Schema 1.0 simple types
Let
Let
Let
Let
Let
Let
Let
Two component instances of the same type are considered equivalent if, for each property of the first component, there is a corresponding property with an equivalent value on the second component, and vice versa.
Instances of properties of the same type are considered equivalent if their values are equivalent.
For values of a simple type (see
Values which are references to other components are considered equivalent when they refer to equivalent components (as determined above).
List-based values are considered equivalent if they have the same length and their elements at corresponding positions are equivalent.
Finally, set-based values are considered equivalent if for each value in the first, there is an equivalent value in the second, and vice versa.
Extension properties which are not string values, sets of strings or references MUST describe their values' equivalence rules.
Because different top-level components (e.g.,
This specification defines three symbol spaces, one for each top-level
component type (
Within a symbol space, all qualified names (that is, the
When XML Schema is being used as one of the type systems for a
WSDL 2.0 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 2.0 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. The namespace name for a component is represented by the
value of the
QName references are resolved by looking in the appropriate
property of the
If the appropriate property of the
This specification uses absolute URIs and IRIs to identify several
components (for example, features and properties) and components
characteristics (for example, operation message exchange patterns
and styles). When such absolute URIs and IRIs are being compared to determine
equivalence (see
The content of messages and faults may be constrained using type system components. These constraints are based upon a specific data model, and expressed using a particular schema language.
Although a variety of data models can be accommodated (through WSDL 2.0
extensions), this specification only defines a means of expressing
constraints based upon the XML Infoset
Specifically, the
When extensions are used to enable the use of a non-Infoset data model,
or a non-Schema constraint language, the
Support for the W3C XML Schema
The schema components contained in the
The schema components contained in the
The
A [local name] of
A [namespace name] of
Zero or more namespace qualified
Zero or more
Zero or more
Zero or more
Other namespace qualified
XML Schema MAY be used as the schema language via import or inlining.
| XML Representation | Referenceability of XML Schema Components | |
|---|---|---|
| Including description | description/include |
XML Schema components in the included |
| Importing description | description/import |
None of the XML Schema Components in the imported |
| Importing XML Schema | description/types/xs:import |
|
| Inlined XML Schema | description/types/xs:schema |
|
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
It is an error if a QName is not resolved (see
Inlining an XML schema uses the existing top-level
The schema components defined and declared in the inlined schema
document are referenceable by QName (see
Similarly, components defined in an inlined XML schema are NOT
automatically referenceable within WSDL 2.0 document that imported
(using
Inside an inlined XML schema, the
A WSDL 2.0 document MAY inline two or more schemas from the
same
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 inlined or imported, the element declarations present in a
schema are referenceable from an
A named, global
A named, global
Since it is unreasonable to expect that a single schema language can
be used to describe all possible
See
This specification does not define the behavior of a WSDL 2.0 document that uses multiple schema languages for describing type system components simultaneously.
Web services may exchange messages that refer to other Web
services or Web service endpoints. If the interface or
binding of these referenced services or endpoints are known
at description time, then it may be useful to include this
information in the WSDL 2.0 document that describes the Web
service. WSDL 2.0 provides two global
WSDL 2.0 defines
the use of these global
WSDL 2.0 provides a global
A [local name] of
A [namespace name] of
The type of the
WSDL 2.0 provides a global
A [local name] of
A [namespace name] of
The type of the
The
This specification provides two mechanisms, described in this section, for modularizing WSDL 2.0 descriptions. These mechanisms help to make WSDL 2.0 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 2.0 components and NOT at the level of XML Information Sets or XML 1.0 serializations.
The WSDL 2.0
The WSDL 2.0
A mutual include is direct inclusion by one WSDL 2.0 document of another WSDL 2.0 document which includes the first. A circular include achieves the same effect with greater indirection (A s B includes C includes A, for instance). Multiple inclusion of a single WSDL 2.0 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 2.0 document has the same meaning as including it only once.
The
A [local name] of
A [namespace name] of
One or more
A REQUIRED
Zero or more namespace qualified
Zero or more
Zero or more
Zero or more namespace-qualified
The
A [local name] of
A [namespace name] which has no value.
A
It is an error if the IRI indicated by
The actual value of the
Every top-level WSDL 2.0 component is associated with a target namespace.
On its
The WSDL 2.0
As with XML schema, each WSDL 2.0 document making references
to components in a given (foreign) namespace MUST
have a
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
One or more
A REQUIRED
An OPTIONAL
Zero or more namespace qualified
Zero or more
Zero or more
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 2.0 uses the optional
Like other
The
A [local name] of
A [namespace name] of
Zero or more
Zero or more child
Zero or more
In addition to extensibility implied by the
WSDL 2.0 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 2.0 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 2.0 specification. WSDL 2.0 recommends that specifications defining such protocols also define any necessary WSDL 2.0 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 2.0 document. Thus, a NON-mandatory extension merely provides additional description of capabilities of the service. This specification does not provide a mechanism to mark extension attributes as being required. Therefore, all extension attributes are NON-mandatory.
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 2.0 document.
If a WSDL 2.0 document declares an extension, Feature or Property as optional
(i.e., NON-mandatory), then the Web service MUST NOT assume that the
client supports that extension, Feature or Property,
A key purpose of an extension is to formally indicate (i.e., in a machine-processable way) that a particular feature or convention is supported or required. This enables toolkits that understand the extension to engage it automatically, while toolkits that do not yet understand a required extension may be able to flag it to an operator for manual support.
If a Web service requires the client to follow a particular convention that is likely to be automatable in WSDL 2.0 toolkits, then that convention SHOULD be indicated in the WSDL 2.0 document as a wsdl:required extension, rather than just being conveyed out of band, even if that convention is not currently implemented in WSDL 2.0 toolkits.
This practice will help prevent interoperability problems that could arise if one toolkit requires a particular convention that is not indicated in the WSDL 2.0 document, while another toolkit does not realize that that convention is required. It will also help facilitate future automatic processing by WSDL 2.0 toolkits.
On the other hand, a client MAY engage an extension, Feature or Property that is declared as optional in the WSDL 2.0 document. Therefore, the Web service MUST support every extension, Feature or Property that is declared as optional in the WSDL 2.0 document, in addition to supporting every extension, Feature or Property that is declared as mandatory.
If finer-grain, direction-sensitive control of extensions, Features or Properties is desired, then such extensions, Features or Properties may be designed in a direction-sensitive manner (from the client or from the Web service) so that either direction may be separately marked required or optional. For example, instead of defining a single extension that governs both directions, two extensions could be defined -- one for each direction.
WSDL 2.0 provides a global
A [local name] of
A [namespace name] of
The type of the
WSDL 2.0 allows qualified
WSDL 2.0 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 2.0 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 2.0 document in ways that invalidate the existing semantics.
Extensibility elements SHOULD NOT alter the existing semantics in ways that are likely to confuse users.
However, once the client and service both know that an optional feature has been engaged (because the service has received a message explicitly engaging that feature, for example), then the semantics of that feature supersede what the WSDL 2.0 document indicated. For example, the WSDL 2.0 document may have specified an XML message schema to be used, but also indicated an optional security feature that encrypts the messages. If the security feature is engaged, then the encrypted messages will no longer conform to the specified message schema (until they are decrypted).
Authors of extensibility elements should make sure to
include in the specification for such elements a clear statement
of the requirements for document conformance (see
As an XML vocabulary, WSDL documents, WSDL fragments or
references to WSDL components -via QNames- MAY appear within other
XML documents. This specification defines a global attribute,
The
A normative XML Schema
WSDL 2.0 provides a global
A [local name] of
A [namespace name] of
The type of the
This sections describes how this specification conforms
to other specifications. At present, only one other
specification, XML Information Set, is included here. Refer to
This specification conforms to the
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
Either a syntax identical to that of
As specified in
WSDL
World Wide Web Consortium <web-human@w3.org>
COMMON
The WSDL 2.0 specification set is a work product of the World Wide
Web Consortium's
This section defines a fragment identifier syntax for identifying components of a WSDL 2.0 document.
This fragment identifier syntax is compliant with the
A WSDL 2.0 fragment identifier consists of zero or more xmlns pointer parts
followed by a WSDL 2.0 pointer part as defined below.
The pointer parts have a scheme name that corresponds to one
of the standard WSDL 2.0 component types, and scheme data that is a path composed
of names that identify the components.
The scheme names all begin with the prefix "wsdl." to avoid
name conflicts with other schemes.
The names in the path are of type either QName, NCName,
IRI, URI, or Pointer Part depending on the context.
The scheme data for extension components is defined by the
corresponding extension specification.
For QNames, any prefix MUST be defined by a preceding xmlns pointer part. If a QName does not have a prefix then its namespace name is the target namespace of the WSDL 2.0 document.
The fragment identifier is typically constructed from the
| Component | 1 | 2 | 3 | 4 | Pointer Part |
|---|---|---|---|---|---|
| n/a | n/a | n/a | n/a | |
|
|
n/a | n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
n/a | n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
n/a | n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
|
|
n/a | |
|
|
|
|
|
|
|
|
n/a | n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
|
|
n/a | |
|
|
|
|
|
|
|
|
n/a | n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
|
n/a | n/a | |
|
|
|
n/a | n/a | |
Note that the above rules are defined in terms of component properties rather than the XML Infoset representation of the component model. The following sections specify in detail how the pointer parts are constructed from the component model.
Let
An IRI-reference consists of an IRI and a fragment
identifier. IRI-references for WSDL 2.0 documents consist
of an IRI that dereferences to a resource whose media type
is
application/wsdl+xml
and a fragment identifier that conforms to XPointer syntax
including the WSDL 2.0 pointer part schemes defined here.
The interpretation of the WSDL 2.0 pointer parts is
defined in terms of
Let
We refer to the namespace of the WSDL 2.0 document as the
Let
Let
The namespace of a
The namespace of an
The namespace of a nested component is equal to the namespace of its parent:
The syntax of extension component identifiers is defined by the corresponding extension specification.
Let
Let
Let
This map will be defined for each component in the following sections.
Let
wsdl.description()
The description fragment identifier has no arguments and designates the unique
The pointer part defined by a
wsdl.elementDeclaration(
wsdl.elementDeclaration(
is the
is the namespace absolute IRI of the extension type system used
for the
Let
Let
Let
The pointer part defined by an
wsdl.typeDefinition(
wsdl.typeDefinition(
is the
is the namespace absolute IRI of the extension type system used
for the
Let
Let
The pointer part defined by a
wsdl.interface(
is the local name of the
Let
Let
The pointer part defined by an
wsdl.interfaceFault(
is the local name of the
is the local name of the
Let
Let
The pointer part defined by an
wsdl.interfaceOperation(
is the local name of the
is the local name of the
Let
Let
The pointer part defined by an
wsdl.interfaceMessageReference(
is the local name of the
is the local name of the
is the
Let
Let
The pointer part defined by an
wsdl.interfaceFaultReference(
is the local name of the
is the local name of the
is the
is the
Let
Let
The pointer part defined by an
wsdl.binding(
is the local name of the
Let
Let
Note that the above definition applies to all
The pointer part defined by a
Let
wsdl.bindingFault(
is the local name of the
is the
Let
Let
The pointer part defined by a
wsdl.bindingOperation(
is the local name of the
is the
Let
Let
The pointer part defined by a
wsdl.bindingMessageReference(
is the local name of the
is the
is the
Let
Let
The pointer part defined by a
wsdl.bindingFaultReference(
is the local name of the
is the
is the
is the
Let
Let
The pointer part defined by a
wsdl.service(
is the local name of the
Let
Let
The pointer part defined by a
wsdl.endpoint(
is the local name of the
is the
Let
Let
The pointer part defined by a
wsdl.feature(
is the pointer part of the parent component.
is the
Let
Let
The pointer part defined by a
wsdl.property(
is the pointer part of the parent component.
is the
Let
Let
The pointer part defined by a
WSDL 2.0 is extensible and it is possible for an extension to define new components types. The XPointer Framework scheme for extension components is:
wsdl.extension(
is the namespace URI that identifies the extension, e.g.
for the WSDL 2.0 SOAP 1.2 Binding the namespace is
http://www.w3.org/2006/01/wsdl/soap.
is defined by the extension using a syntax specific to the extension.
The owner of the
extension must define any components contributed by
the extension and a syntax for identifying them.
Let
Let
The details of the association are defined by each extension specification.
The namespace IRI of an extension component is defined by the extension specification.
The pointer part defined by an
extension
component is
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): Charlton Barreto (Adobe Systems Inc.), Allen Brookes (Rogue Wave Softwave), Dave Chappell (Sonic Software), Helen Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun Microsystems), Kendall Clark (University of Maryland), Glen Daniels (Sonic Software), Paul Downey (British Telecommunications), Youenn Fablet (Canon), Hugo Haas (W3C), Tom Jordahl (Macromedia), Anish Karmarkar (Oracle Corporation), Jacek Kopecky (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria), Amelia Lewis (TIBCO Software, Inc.), Michael Liddy (Education.au Ltd.), Kevin Canyang Liu (SAP AG), Jonathan Marsh (Microsoft Corporation), Josephine Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau (Canon), Mark Nottingham (BEA Systems, Inc.), David Orchard (BEA Systems, Inc.), Vivek Pandey (Sun Microsystems), Bijan Parsia (University of Maryland), Gilbert Pilz (BEA Systems, Inc.), Tony Rogers (Computer Associates), Arthur Ryman (IBM), Adi Sakala (IONA Technologies), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçınalp (SAP AG).
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), Sandra Swearingen (U.S. Department of Defense, U.S. Air Force), 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), Michael Mahan (Nokia), Bryan Thompson (Hicks & Associates), Ingo Melzer (DaimlerChrysler Research and Technology), Sandeep Kumar (Cisco Systems), Alan Davies (SeeBeyond), Jacek Kopecky (Systinet), Mike Ballantyne (Electronic Data Systems), Mike Davoren (W. W. Grainger), Dan Kulp (IONA Technologies), Mike McHugh (W. W. Grainger), Michael Mealling (Verisign), Waqar Sadiq (Electronic Data Systems), Yaron Goland (BEA Systems, Inc.), Ümit Yalçınalp (Oracle Corporation), Peter Madziak (Agfa-Gevaert N. V.), Jeffrey Schlimmer (Microsoft Corporation), Hao He (The Thomson Corporation), Erik Ackerman (Lexmark), Jerry Thrasher (Lexmark), Prasad Yendluri (webMethods, Inc.), William Vambenepe (Hewlett-Packard Company), David Booth (W3C), Sanjiva Weerawarana (IBM), Charlton Barreto (webMethods, Inc.), Asir Vedamuthu (webMethods, Inc.), Igor Sedukhin (Computer Associates), Martin Gudgin (Microsoft Corporation), Rebecca Bergersen (IONA Technologies), Ugo Corda (SeeBeyond).
The people who have contributed to
This appendix provides a syntax for IRI-references for all components found in a WSDL 2.0 document. The IRI-references are easy to understand and compare, while imposing no burden on the WSDL 2.0 author.
There are two main cases for WSDL 2.0 IRIs:
the IRI of a WSDL 2.0 document
the IRI of a WSDL 2.0 namespace
The IRI of a WSDL 2.0 document can be dereferenced to give a resource representation that contributes component definitions to a single WSDL 2.0 namespace. If the media type is set to the WSDL 2.0 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 IRI in an IRI-reference for a WSDL 2.0 component is the namespace
name of the
Consider the following WSDL 2.0 document located at http://example.org/TicketAgent.wsdl:
Its components have the following IRI-references:
| Component | Defined Properties |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Property | Where Defined |
| address | Endpoint. |
| binding | Endpoint. |
| binding faults | Binding. |
| binding operations | Binding. |
| bindings | Description. |
| direction | Interface Fault Reference. |
| element declaration | Interface Fault. |
| element declarations | Description. |
| endpoints | Service. |
| extended interfaces | Interface. |
| features | . |
| interface | Binding. |
| interface fault | Binding Fault. |
| interface fault references | Interface Operation. |
| interface faults | Interface. |
| interface message references | Interface Operation. |
| interface operations | Interface. |
| interfaces | Description. |
| message content model | Interface Message Reference. |
| message exchange pattern | Interface Operation. |
| message label | Interface Fault Reference. |
| name | . |
| parent | . |
| properties | . |
| ref | Feature. |
| required | Feature. |
| services | Description. |
| style | Interface Operation. |
| system | Element Declaration. |
| type | Binding. |
| type definitions | Description. |
| value | Property. |
| value constraint | Property. |
| Date | Author | Description |
|---|---|---|
| 20051121 | AGR |
Added assertions posted to mailing list:
|
| 20051118 | AGR |
Added assertions posted to mailing list:
|
| 20051118 | AGR | Simiplified Z Notation for fragment identifiers and updated |
| 20051117 | AGR | |
| 20051117 | AGR |
Fixed typos posted to mailing list:
|
| 20051117 | JJM | |
| 20051117 | JJM | |
| 20051117 | JJM | |
| 20051117 | JJM | |
| 20051116 | AGR | Added Z Notation for fragment identifiers and component designators for Description, Feature, Property, and Extension components in
|
| 20051115 | AGR | Added Z Notation for fragment identifiers and component designators for Element Declaration and Type Definition components in
|
| 20051113 | AGR | Added Z Notation for fragment identifiers and component designators for Interface, Binding, and Service component families in
|
| 20051112 | AGR | Corrected order of arguments in fragment identifier for
|
| 20051112 | AGR | |
| 20051112 | AGR | |
| 20051112 | AGR | |
| 20051112 | AGR | |
| 20051112 | AGR | |
| 20051110 | AGR | |
| 20051110 | JJM | |
| 20051110 | JJM | |
| 20051110 | JJM | |
| 20051103 | AGR | |
| 20051101 | AGR |
Added Z Notation for message exchange pattern, placeholder
message, and fault propagation ruleset in
|
| 20051027 | AGR | Added bidirectional linking between assertions and the summary table, and added a section on notation, |
| 20051027 | AGR | Updated |
| 20051027 | AGR | |
| 20051020 | AGR | |
| 20051016 | AGR | |
| 20050924 | AGR | Added initial markup for assertions. |
| 20050914 | AGR | |
| 20050914 | AGR | |
| 20050914 | AGR | |
| 20050901 | RRC | |
| 20050730 | AGR | Removed obsolete editorial notes. |
| 20050727 | AGR |
|
| 20050727 | AGR |
|
| 20050727 | AGR | Corrected typo in section 3.1.2 on inlining two or more schemas that have the same namespace. |
| 20050719 | AGR | Added xs:import and xs:schema to XML Syntax Summary for types. |
| 20050711 | AGR | Updated Example C-2. IRI-References - Example IRIs to match Appendix A. |
| 20050616 | AGR | Corrected Feature and Property composition rules for Interface, Service, and Endpoint. |
| 20050615 | AGR | |
| 20050613 | RRC | |
| 20050613 | RRC | |
| 20050613 | AGR | |
| 20050613 | JJM | |
| 20050613 | JJM | |
| 20050613 | JJM | |
| 20050612 | AGR | Finshed first pass at adding markup for WSDL component and property definitions and references. |
| 20050610 | AGR | Added table of components and their properties, courtesy of JM. |
| 20050608 | AGR | Added markup for WSDL component and property definitions and references. |
| 20050602 | HH | |
| 20050601 | JJM | |
| 20050531 | JJM | |
| 20050531 | JJM | |
| 20050526 | AGR | |
| 20050525 | AGR | Added final ComponentModel to Z Notation. |
| 20050523 | AGR | Reordered some paragraphs to improve consistency. |
| 20050522 | AGR | Added consistency and key constraints to the Z notation. |
| 20050520 | JJM | |
| 20050520 | JJM | |
| 20050520 | JJM | Fixed typo in 2.14.1.1. |
| 20050519 | JJM | |
| 20050518 | AGR | Added parent and integrity constraints to the Z notation. |
| 20050513 | JJM | |
| 20050513 | JJM | |
| 20050512 | JJM | |
| 20050511 | AGR | |
| 20050504 | JJM | Rewrote the "Operation Name Mapping Requirement" section to make it best practice. |
| 20050504 | JJM | Removed empty subsections in "XML Schema 1.0 Simple..." |
| 20050504 | JJM | Rewrote the "Single Interface" section, as per editorial AI dated 2005-01-19. |
| 20050503 | JJM | Rewrote the ONMR as Best practice. |
| 20050503 | JJM | |
| 20050503 | JJM | Completed editorial action LC78. |
| 20050501 | AGR | |
| 20050501 | AGR | |
| 20050501 | AGR | |
| 20050501 | AGR | |
| 20050501 | AGR | |
| 20050501 | AGR | |
| 20050501 | AGR | |
| 20050430 | AGR | |
| 20050429 | AV | |
| 20050429 | RRC | |
| 20050429 | RRC | Added clarification that an operation style MAY affect only input or only output messages (or any other combination). |
| 20050421 | AGR |
|
| 20050418 | RRC | |
| 20050418 | RRC | |
| 20050417 | AGR | Interface.{faults} -> {interface faults} Interface.{operations} -> {interface operations} InterfaceFault.{element} -> {element declaration} MessageReference.{element} -> {element declaration} FaultReference.{fault reference} -> {interface fault} Binding.{faults} -> {binding faults} Binding.{operations} -> {binding operations} BindingFault.{fault reference} -> {interface fault} BindingOperation.{operation reference} -> {interface operation} BindingOperation.{message references} -> {binding message references} BindingOperation.{fault references} ->{binding fault references} |
| 20050417 | AGR |
|
| 20050416 | AGR |
|
| 20050416 | AGR | Moved the |
| 20050414 | JJM | Fixed XML Schema P1/P2 version listed in the bibliography section. |
| 20050413 | AGR |
|
| 20050407 | JJM | Reworded the introduction for wsdlLocation, as per LC26 resolution. |
| 20050407 | JJM | Moved paragraphs 6-9 of section 2.1.1 into 2.1.2. |
| 20050331 | AGR |
|
| 20050320 | AGR | |
| 20050320 | AGR | Rename Z Notation versions as wsdl20-z.html and wsdl20-z-ie-html. |
| 20050315 | AGR | Hide Z Notation in the Normative version of the spec. |
| 20050314 | AGR | Removed section on RPC Style so it can be included in Adjuncts. |
| 20050310 | AGR | Fixed minor Binding Operation errors introduced by addition of Binding Message Reference. |
| 20050310 | JJM | Replaced schema visibility table with Asir's revised version. |
| 20050309 | AGR | Fixed minor Z typechecking errors introduced by addition of Binding Message Reference. Kudos to RRC for updating the Z Notation! |
| 20050301 | RRC | |
| 20050301 | RRC | |
| 20050301 | RRC | |
| 20050228 | JJM | |
| 20050228 | JJM | |
| 20050228 | JJM | |
| 20050218 | RRC | Replaced "provider agent" with "Web service" and "requester agent" with "client" (resolution of LC30). |
| 20050218 | RRC | Moved section on the operation name mapping requirement to section 2.13 (resolution of LC8). |
| 20050218 | RRC | Implemented resolution of LC5h. |
| 20050220 | AGR | Refactored Feature and Property Z Notation in preparation for formalization of composition model. |
| 20050220 | AGR |
|
| 20050220 | AGR |
|
| 20050220 | AGR |
|
| 20050220 | AGR | Completed Action Item - 2005-02-10: DBooth to mail Arthur change to wording on media type registration, Arthur to incorporate. |
| 20050217 | JJM |
|
| 20050217 | JJM |
|
| 20050216 | JJM |
|
| 20050216 | JJM |
|
| 20050216 | JJM |
|
| 20050211 | AGR |
|
| 20050210 | AGR |
|
| 20050209 | AGR |
|
| 20050121 | AGR |
|
| 20050121 | AGR |
LC75
|
| 20050120 | AGR |
|
| 20050119 | AGR | Editorial improvements to Z Notation. Added referential integrity constraints. |
| 20050118 | AGR | Edited Notational Conventions and References sections. Added character entity references for accented characters. |
| 20050117 | AGR | Edited table markup to simplify PDF generation. |
| 20041231 | AGR | Added reference to non-normative IE version of the specification. |
| 20041227 | AGR | Added reference to non-normative DHTML version of the specification. |
| 20041218 | AGR | |
| 20041126 | AGR | |
| 20041102 | HH | |
| 20041024 | AGR | Added initial Z Notation for component model. |
| 20040930 | AGR | |
| 20040929 | AGR |
|
| 20040802 | RRC | Removed paragraph added per resolution of issue 211 (undone per action item 5 of the 2004-07-29 concall). |
| 20040802 | RRC | Added clarification on the meaning of required language extensions. |
| 20040802 | RRC | Added operation name requirement to the |
| 20040802 | RRC | Added introductory text for the Property Component (per action item 2 of the 2004-07-29 concall). |
| 20040727 | RRC | Made the |
| 20040727 | SW | Issue 243 text |
| 20040727 | SW | Incorporated Paul's words for issue 235 |
| 20040727 | SW | Added MarkN's text for issue 211 |
| 20040727 | SW | Added note to processor conf rules for optional extensions and features about what optional means. |
| 20040727 | SW | Removed contentious area ed note thing per decision to do those via minority opinions. |
| 20040722 | HH | Defined wsdls:int for http:code. |
| 20040721 | RRC | Made almost all set-valued properties optional and added a rule to default them to the empty set, per agenda item 7 of 2004-07-15 concall. |
| 20040715 | RRC | Marked the {message label} property of the Message Reference and Fault Reference components as required. |
| 20040715 | RRC | Made the {style} property into a set of xs:anyURI. |
| 20040714 | RRC | Added definition of simple types used by the component model (issue 177). |
| 20040713 | RRC | Added clarification to interface extensions per issue 220. |
| 20040713 | RRC | Added clarification to Binding Operation section (issue 227). |
| 20040713 | RRC | Fixed references to |
| 20040713 | RRC | Added description of pseudo-schema syntax. |
| 20040714 | SW | Made f&p allowed in the remaining places and updated composition rules |
| 20040713 | SW | Added negative conformance criteria: not required to process XML1.1 etc. |
| 20040713 | SW | Corrected reference to frag ID syntax to for issue 209 |
| 20040713 | SW | Implemented Jonathan's proposal for issue 160. |
| 20040713 | SW | Put ednote in contentious areas asking for extra feedback. |
| 20040712 | RRC | Marked all component model properties as REQUIRED or OPTIONAL (issue 213). |
| 20040712 | RRC | Added definition for equivalence of list-typed values. |
| 20040712 | RRC | Clarified RPC style rules for one-way operations (issue 215). |
| 20040708 | JJM | Finished adding clarifications for non-XML type system extensibility. |
| 20040708 | JJM | Include the definition of "actual value" from XML Schema (Issue 219). |
| 20040708 | JJM | Added resolution to issue 218 (2004Jun/0276.html, including Mark's amendment). |
| 20040708 | JJM | Component equivalence (2004Jun/0195.html, 2004Jun/0199.html and ref to the charmod [Issue 210]). |
| 20040706 | RRC | Added clarifications for non-XML type system extensibility. |
| 20040706 | RRC | Expanded component model definition. |
| 20040706 | RRC | Added clarification to section 2.1.1 per resolution of issue 222. |
| 20040706 | RRC | Made it possible to use rpc style with schema languages other than XML Schema. |
| 20040702 | SW | Made operation/@style be a list of URIs. |
| 20040702 | SW | Had forgotten to map to the {type} property of binding. |
| 20040625 | SW | Allowed F&P *nearly* everywhere. Sigh. |
| 20040618 | SW | Changed F&P composition model to nearest enclosing scope. |
| 20040618 | SW | Incorporated Jacek's purpose of bindings text as appropriate. |
| 20040526 | SW | Added @address to /definitions/service/endpoint per F2F decision |
| 20040526 | SW | Added @type to /definitions/binding per F2F decision |
| 20040519 | SW | Renamed wsoap12: to wsoap:. |
| 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 |
| 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 'mig_porttypes' |
| 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 |
| 20030303 | MJG | Skeleton Feature and |
| 20030305 | MJG | Merged ComponentModelForMEPs branch (1.46.2.5) into main branch (1.54). Below is change log from the branch: |
| 20030220 | MJG | ComponentModelForMEPs: Minor wording change at suggestion of JJM |
| 20030212 | MJG | ComponentModelForMEPs: Updated component model to include Fault Reference component. Associated changes to Port Type Operation component |
| 20030211 | MJG | ComponentModelForMEPs: Changes to component model to support MEPs |
| 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 dbooth's 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. |
| 20030130 | MJG | operationnames: Updated binding section to match changes to port type section WRT operation names |
| 20030130 | MJG | operationnames: Added best practice note on operation names and target
namespaces to |
| 20030122 | MJG | operationnames: Started work on making operations have unique names |
| 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 |
| 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 |
This appendix summarizes assertions about WSDL 2.0 documents and components that are not enforced by the WSDL 2.0 schema. Each assertion is assigned a unique identifier which WSDL 2.0 processors may use to report errors.
| Id | Assertion |
|---|---|
|
|
Its value
MUST be an absolute IRI (see |
|
|
However, any WSDL 2.0 document that contains component
definitions that refer by QName to WSDL 2.0 components
that belong to a different namespace MUST contain a
|
|
|
Imported components have different target namespace values from the WSDL 2.0 document that is importing them. |
|
|
Its value, if present, MUST contain
absolute IRIs (see |
|
|
The
|
|
|
The
|
|
|
The
|
|
|
The
|
|
|
If the
|
|
|
If the
|
|
|
If the
|
|
|
If the
|
|
|
If the
|
|
|
If the
|
|
|
If the
|
|
|
If the
|
|
|
A WSDL 2.0 document MUST NOT refer to XML Schema components in a given
namespace unless an |
|
|
The referenced schema MUST contain
a |
|
|
A WSDL 2.0 document MUST NOT define the same element or type in more than one inlined schema. |
|
|
The |
|
|
An |
|
|
A specification of extension syntax for an alternative schema language MUST use a namespace that is different than the namespace of XML Schema. |
|
|
If
|
|
|
The value of the |
|
|
The namespace used for an alternate schema language MUST be an absolute IRI. |
|
|
A specification of extension syntax
for an alternative schema language MUST include the declaration of an |
| Id | Assertion |
|---|---|
|
|
Each WSDL 2.0 or type system component MUST be uniquely identified by its qualified name. |
|
|
This |
|
|
The |
|
|
To avoid circular definitions, an interface MUST NOT appear as an element of the set of interfaces it extends, either directly or indirectly. |
|
|
For each |
|
|
The namespace name of the |
|
|
For each
|
|
|
In cases where, due to an interface extending one or more other
interfaces, two or more
|
|
|
The value of this property MUST match the name of a placeholder message defined by the message exchange pattern. |
|
|
The direction MUST be consistent with the direction implied by the fault propagation ruleset used in the message exchange pattern of the operation. |
|
|
For each |
|
|
The direction MUST be the same as the
direction of the message identified by the
|
|
|
When
the |
|
|
For each |
|
|
The namespace name of the |
|
|
For each
|
|
|
In cases where, due to an interface extending one or more
other interfaces, two or more |
|
|
An |
|
|
A message exchange pattern is uniquely
identified by an absolute IRI which is used as the value
of the
|
|
|
The value of this property MUST match the name of a placeholder message defined by the message exchange pattern. |
|
|
A reference to a
|
|
|
The |
|
|
All specified values MUST be equal and belong to each specified value set. |
|
|
This
|
|
|
Furthermore, all QName references, whether to the same or
to different namespaces MUST resolve to components (see
|
|
|
It is an error if there are multiple type definitions for each QName. |