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
W3C Advisory Committee Representatives should consult their
Individuals are invited to send
feedback on this document to the public
The Working Group released a test suite along with an
Issues about this document are recorded in the
Publication as a Proposed 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 is governed by the
Last Modified: $Date: 2007/05/21 13:42:29 $
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 companion specification,
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
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 interactions with a Web service, not required interactions. 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.
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.
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
| Prefix | Namespace | Notes |
|---|---|---|
| wsdl |
|
Defined by this specification. |
| wsdli |
|
Defined by this specification |
| wsdlx |
|
Defined by this specification |
| wrpc |
|
Defined by WSDL 2.0: Adjuncts |
| wsoap |
|
Defined by WSDL 2.0: Adjuncts |
| whttp |
|
Defined by WSDL 2.0: Adjuncts |
| xs |
|
Defined in the W3C XML Schema
specification |
| xsi |
|
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 implementers 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 by a dagger symbol (†) at the end of a sentence. Each assertion has been assigned a unique identifier that consists of a descriptive textual prefix and a unique numeric suffix. The numeric suffixes are assigned sequentially and never reused so there may be gaps in the sequence. The assertion identifiers MAY be used by implementations of this specification for any purpose, e.g. error reporting.
The assertions and their identifiers are
summarized in section
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 constraints 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
The definition of
The component types in the component model have an identifier. It is convenient to put this field into a base Z schema that can be included in other component schemas.
Let
The base properties of a component are valid when the identifiers 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 a high 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
Let the built-in XML schema datatypes correspond to the following
Let
Let
Both the namespace name of the
Let
The built-in datatypes are distinct so there are forty-four ids in total:
The XML Schema built-in datatypes are also built into WSDL 2.0.
Let
The component model contains a unique
Let
Let
The component model contains a unique
Each component referred to by the properties of the
Let
The
The
The
The
The
The set of top-level components contained in the
When using the XML Schema language to describe type system components,
the inclusion of
In addition to WSDL 2.0 components and type system
components, additional extension components MAY be added via
extensibility
WSDL 2.0 descriptions 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
Components that belong to imported namespaces have different target namespace values than that of the importing WSDL 2.0 document. Thus importing is the mechanism to use components from one namespace in the definition of components from another namespace.
Note that each WSDL 2.0 document or type system component of the
same kind must be uniquely identified by its qualified
name. That is, if two distinct components of the same kind
(
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 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 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 |
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
For each
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
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 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 |
|
| If the
|
|
| If the |
|
|
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
For each
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
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 propagation 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 can therefore be safely ignored in that
context. However, the additional information can 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
An OPTIONAL
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 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 |
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 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
Note that the
Define the
| Property | Value |
|---|---|
| The effective message label. | |
| The message direction. | |
| If the
|
|
| If the |
|
|
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
As indicated earlier, 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 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 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 message reference
Define the
Define the
Define the
Define the
| Property | Value |
|---|---|
|
The
|
|
| The effective message label. | |
| The fault direction. | |
|
The |
A
Conversely, a
No concrete binding details are given in this
specification. The companion specification,
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
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 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 |
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
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 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 |
The
The properties of the
Let
Each component referenced by a
Let
Every
The
The
The
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 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
|
A
The properties of the
Let
Each component referenced by a
Let
Every
The
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 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
Note that the
Define the
| Property | Value |
|---|---|
|
|
The |
| {parent} |
The
|
A
The properties of the
Let
Each component referenced by a
Let
Every
The
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 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
| Property | Value |
|---|---|
|
|
The |
| {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
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 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 |
An
The
The
The properties of the
Let
Each component referenced by a
Let
Every
The
For each
Let
No two
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 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
|
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 value of the first component, there is a corresponding property with an equivalent value on the second component, and vice versa.
For values of a simple type (see true or
false).
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.
Because different top-level components (e.g.,
The
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 and components
characteristics (for example, operation message exchange patterns
and styles).
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
Extensions in the form of
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
Every QName reference must
resolve (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
Note that components in the namespace that the inline schema imports via
Note that components defined in an
inlined XML schema are not automatically referenceable within the 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
Additional OPTIONAL
Zero or more child
Whether inlined or imported, the global element declarations present in a
schema are referenceable from an
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 can 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
WSDL 2.0 provides a global
A [local name] of
A [namespace name] of
The
WSDL 2.0 provides two mechanisms for modularizing WSDL 2.0 descriptions. These mechanisms help to make Web service descriptions clearer by allowing separation of the various components of a description. Such separation can 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 even 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 the direct inclusion by one WSDL 2.0 document of another WSDL 2.0 document which includes the first document. A circular include achieves the same effect with greater indirection (for example, A includes B, B includes C, and C includes A). Multiple inclusion of a single WSDL 2.0 document resolves to a single set of components, as if the document was included only once. Mutual, multiple, and circular includes are explicitly permitted, and do not represent multiple redefinitions of the same components.
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
Every top-level WSDL 2.0 component is associated with a namespace.
Every WSDL 2.0 document carries a
The WSDL 2.0
Using 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
This restriction on the behavior of extensions permits WSDL
2.0 documents to be flexibly modularized and efficiently
processed. In contrast, note that the so-called chameleon
include mechanism of XML Schema, which allows a no-namespace
schema to be included in a schema document that has a
namespace, violates this restriction since the namespace of
the included XML Schema components is determined by the
including XML Schema document (see 4.2.1 Assembling a schema
for a single target namespace from multiple schema
definition documents in
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
The schema for WSDL 2.0 has a two-part
extensibility model based on namespace-qualified elements and attributes.
An extension is identified by the QName consisting of its
namespace IRI and its element or attribute name.
WSDL 2.0 allows extensions to be defined in terms of
It is expected that extensions will add to the
existing properties of components in the component model. The
specification for an extension
The WSDL 2.0 schema defines a base type for use by extension
elements.
Extension 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
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.
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 can possibly bring it to the attention of an operator for manual support.
If a Web service requires a 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
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
that is declared as optional in the WSDL 2.0 document.
If finer-grain, direction-sensitive control of extensions is desired, then such extensions 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.
Validity of a WSDL 2.0 document can only be assessed within the context of a set of supported extensions. A WSDL 2.0 document that contains a required but unsupported extension is invalid with respect to that set of supported extensions.
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 extension elements and attributes will result in additional properties appearing in the component model.
The presence of an optional extension 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 extension element MAY alter the semantics of a WSDL 2.0 document in ways that invalidate the existing semantics.
Extension elements SHOULD NOT alter the existing semantics in ways that are likely to confuse users.
Note that, however, once the client and service both know that an optional extension has been engaged (because the service has received a message explicitly engaging that extension, for example), then the semantics of that extension 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 extension that encrypts the messages. If the security extension is engaged, then the encrypted messages will no longer conform to the specified message schema (until they are decrypted).
Authors of extension elements should make sure to
include in the specification of these elements a clear statement
of the requirements for document conformance (see
Authors of extension elements that may manifest as properties of
the
A
As an XML vocabulary, WSDL 2.0 documents, WSDL2.0 document fragments or QName
references to WSDL 2.0 components 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 section describes how this specification conforms
to other specifications. This is limited, at present,
to the XML Information Set spefication. 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 is an XPointer xmlns pointer
parts (see
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 | |
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 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/ns/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), Ram Jeyaraman (Microsoft), Tom Jordahl (Adobe Systems), Anish Karmarkar (Oracle Corporation), Jacek Kopecky (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria), Amelia Lewis (TIBCO Software, Inc.), Philippe Le Hegaret (W3C), Michael Liddy (Education.au Ltd.), Kevin Canyang Liu (SAP AG), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems), Josephine Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau (Canon), David Orchard (BEA Systems, Inc.), Gilbert Pilz (BEA Systems, Inc.), Tony Rogers (Computer Associates), Arthur Ryman (IBM), Adi Sakala (IONA Technologies), Michael Shepherd (Xerox), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçınalp (SAP AG), Peter Zehler (Xerox).
Previous members were: Eran Chinthaka (WSO2), Mark Nottingham (BEA Systems, Inc.), Hugo Haas (W3C), Vivek Pandey (Sun Microsystems), Bijan Parsia (University of Maryland), 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), 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
xmlns
pointer parts (see
The IRI-references described above MAY be used as WSDL 2.0 component designators. For ease of comparison, the fragment identifier of WSDL 2.0 component designators SHOULD conform to the following canonicalization rules:
xmlns()
pointer parts followed by exactly one
wsdl.*()
pointer part.
xmlns()
pointer part that appears in the fragment
identifier defines a namespace that is
referenced by the
wsdl.*()
pointer part.
xmlns()
pointer part defines a unique namespace.
xmlns()
pointer parts define namespaces in the same
order as they are referenced in the
wsdl.*()
pointer part.
xmlns()
pointer parts are named
ns1
,
ns2
, etc., in the order of their appearance.
xmlns() pointer part defines a namespace for the targetNamespace of the
WSDL 2.0 document.
Consider the following WSDL 2.0 document located at http://example.org/TicketAgent.wsdl:
Its components have the following IRI-references which follow the above canonicalization rules except for the presence of optional whitespace that has been added in order to improve the formatting:
| Component | Defined Properties |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Property | Where Defined |
| address | Endpoint. |
| binding | Endpoint. |
| binding fault references | Binding Operation. |
| binding faults | Binding. |
| binding message references | Binding Operation. |
| binding operations | Binding. |
| bindings | Description. |
| direction | Interface Fault Reference. |
| element declaration | Interface Fault. |
| element declarations | Description. |
| endpoints | Service. |
| extended interfaces | Interface. |
| interface | Binding. |
| interface fault | Binding Fault. |
| interface fault reference | Binding Fault Reference. |
| interface fault references | Interface Operation. |
| interface faults | Interface. |
| interface message reference | Binding Message Reference. |
| interface message references | Interface Operation. |
| interface operation | Binding Operation. |
| interface operations | Interface. |
| interfaces | Description. |
| message content model | Interface Fault. |
| message exchange pattern | Interface Operation. |
| message label | Interface Fault Reference. |
| name | . |
| parent | . |
| services | Description. |
| style | Interface Operation. |
| system | Element Declaration. |
| type | Binding. |
| type definitions | Description. |
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 |
|---|---|
|
|
If a WSDL 2.0 document is split into multiple WSDL 2.0 documents
(which may be combined as needed via |
|
|
Zero or more |
|
|
Its value
MUST be an absolute IRI (see |
|
|
As with XML schema, any WSDL 2.0 document that references
a foreign component MUST
have a |
|
|
If a WSDL 2.0 document contains more than one |
|
|
This value MUST NOT match the actual
value of |
|
|
If the location attribute in the |
|
|
If the |
|
|
The IRI indicated by |
|
|
The actual value of the |
|
|
Its value, if present, MUST contain
absolute IRIs (see |
|
|
If the |
|
|
The |
|
|
If the |
|
|
It MUST NOT appear on a
|
|
|
For each pair of IRIs, if the location IRI of the pair is dereferencable, then it MUST reference a WSDL 2.0 (or 1.1) document whose target namespace is the namespace IRI of the pair. |
|
|
If the
|
|
|
If the
|
|
|
If the local name is |
|
|
If the local name is |
|
|
If the local name is |
|
|
If the local name is |
|
|
The
|
|
|
If the
|
|
|
If the
|
|
|
If the
|
|
|
If the
|
|
|
The
|
|
|
If the
|
|
|
If the
|
|
|
A |
|
|
A WSDL 2.0 document MUST NOT refer to XML Schema components in a given
namespace UNLESS an |
|
|
The referenced schema MUST contain
a |
|
|
The value of the |
|
|
A WSDL 2.0 document MUST NOT define the same element or type in more than one inlined schema. |
|
|
A specification of extension syntax for an alternative schema language MUST use a namespace that is different than the namespace of XML Schema. |
|
|
The namespace used for an alternate schema language MUST be an absolute IRI. |
|
|
If
|
|
|
A specification of extension syntax
for an alternative schema language MUST include the declaration of an |
|
|
The type of the
|
|
|
The type of the
|
| Id | Assertion |
|---|---|
|
|
If a |
|
|
A |
|
|
Similarly, whenever a reusable |
|
|
A |
|
|
This |
|
|
For each |
|
|
For each
|
|
|
For each
|
|
|
There MUST be an |
|
|
For each
|
|
|
For each
|
|
|
The fragment identifier consists of a sequence
zero or more
xmlns()
pointer parts followed by exactly one
wsdl.*()
pointer part.
|
|
|
Each
xmlns()
pointer part that appears in the fragment
identifier defines a namespace that is
referenced by the
wsdl.*()
pointer part.
|
|
|
Each
xmlns()
pointer part defines a unique namespace.
|
|
|
The
xmlns()
pointer parts define namespaces in the same
order as they are referenced in the
wsdl.*()
pointer part.
|
|
|
The namespace prefixes defined by the
xmlns()
pointer parts are named
ns1
,
ns2
, etc., in the order of their appearance.
|
|
|
The fragment identifier contains no optional whitespace. |
|
|
No xmlns() pointer part defines a namespace for the targetNamespace of the
WSDL 2.0 document.
|
|
|
When such absolute URIs and IRIs are being compared to determine
equivalence (see |
|
|
The value of the |
|
|
It SHOULD resolve to a human or machine processable document that directly or indirectly defines the intended semantics of those components. |
|
|
It MAY resolve to a WSDL 2.0 document that provides service description information for that namespace. |
|
|
For each component in the imported namespace, a corresponding
|
|
|
Schema components not in an imported namespace MUST NOT appear in the
|
|
|
For each component
defined and declared in the inlined schema document or included by |
|
|
Schema components not defined or declared in the inlined schema document or included by
|
|
|
This |
|
|
For each
|
|
|
Extension properties which are not string values, sets of strings or references MUST describe their values' equivalence rules. |
|
|
An extension that is NOT marked as mandatory MUST NOT invalidate the meaning of any part of a WSDL 2.0 document. |
|
|
If a WSDL 2.0 document declares an extension as optional
(i.e., NON-mandatory), then the Web service MUST NOT assume that the
client supports that extension |
|
|
Therefore, the Web service MUST support every extension that is declared as optional in the WSDL 2.0 document, in addition to supporting every extension that is declared as mandatory. |
|
|
The meaning of an extension SHOULD be defined (directly or indirectly) in a document that is available at its namespace IRI. |
|
|
For QNames, any prefix MUST be defined by a preceding xmlns pointer part. |
|
|
The fragment identifier in a WSDL 2.0 component IRI-reference
MUST resolve to some component as defined by the construction rules
in |
|
|
The semantics of an extension MUST NOT depend on how components are brought into a component model instance via <import> or <include>. |
|
|
To avoid circular definitions, an interface MUST NOT appear in the set of interfaces it extends, either directly or indirectly. |
|
|
For each |
|
|
The list of |
|
|
An
|
|
|
When
the |
|
|
In cases where, due to an interface extending one or more other
interfaces, two or more
|
|
|
For the above reason, it is considered good practice to
ensure, where necessary, that the local name of the |
|
|
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 |
|
|
An |
|
|
The direction MUST be the same as the
direction of the message identified by the
|
|
|
An
|
|
|
When
the |
|
|
For each |
|
|
This |
|
|
These |
|
|
In cases where, due to an interface extending one or more
other interfaces, two or more |
|
|
For the above reason, it is considered good practice to
ensure, where necessary, that the |
|
|
An |
|
|
Its actual value MUST be a list of
pairs of IRIs; where the first IRI of a pair, which MUST be an
absolute IRI as defined in |
|
|
A message exchange pattern is itself 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. |
|
|
For each
|
|
|
Each XML Schema element declaration MUST have a unique QName. |
|
|
Each XML Schema type definition MUST have a unique QName. |
| Date | Author | Description |
|---|---|---|
| 20070518 | AGR | Correct XML Schema Description to XML Schema Definition. |
| 20070518 | AGR | Fixed typo in base64Binary. |
| 20070425 | AGR | Fixed typo in Example C-2. Replaced xsTicketAgent: with ns1:. |
| 20070419 | JJM | 4431: Add value. |
| 20070419 | JJM | 4430: Fix section reference. |
| 20070319 | JJM | Final minor typos corrections. |
| 20070308 | AGR |
|
| 20070227 | JJM | Reorder bibentries for increased readability. |
| 20070225 | AGR | Renumbered assertions for PR. |
| 20070222 | RRC |
|
| 20070222 | RRC |
|
| 20070222 | JJM |
|
| 20070222 | JJM |
|
| 20070220 | JJM |
|
| 20070220 | JJM | Spell-checked. |
| 20070216 | JJM | Revised wording for CR126. |
| 20070216 | JJM | Fixed description of Part 2 in intro. Updated reference for SOAP12 to Second Edition. |
| 20070215 | JJM |
|
| 20070215 | JJM |
|
| 20070215 | JJM |
|
| 20070215 | JJM |
|
| 20070215 | JJM |
|
| 20070215 | JJM |
|
| 20070212 | JJM |
|
| 20070212 | JJM |
|
| 20070208 | AGR |
Corrected cardinality of
|
| 20070208 | AGR |
|
| 20070110 | AGR |
|
| 20070115 | AGR | Removed feature and property elements from XML pseudo-syntax. |
| 20070110 | AGR |
|
| 20070110 | AGR |
|
| 20070110 | AGR |
|
| 20070110 | AGR |
|
| 20070110 | AGR |
|
| 20070110 | AGR |
|
| 20070110 | AGR |
|
| 20070110 | AGR |
|
| 20070110 | AGR |
|
| 20061221 | AGR |
|
| 20061221 | AGR | |
| 20061221 | AGR | |
| 20061213 | AGR | |
| 20061213 | AGR | |
| 20061111 | AGR |
|
| 20061019 | AGR |
|
| 20061011 | AGR |
|
| 20061011 | AGR |
|
| 20061011 | AGR |
|
| 20060908 | JJM |
|
| 20060908 | JJM |
|
| 20060908 | JJM |
|
| 20060907 | JJM |
|
| 20060907 | JJM |
|
| 20060907 | JJM |
|
| 20060719 | AGR | Minor editorial correction in chapter 6: element or attribute |
| 20060719 | AGR | Minor editorial correction in chapter 6: element or attribute |
| 20060713 | AGR | Made editorial change: use the term "extension" element or attribute consistently rather than "extensibility" element or attribute. |
| 20060503 | AGR | Made editorial improvements to fragment identifier section A.2. |
| 20060418 | AGR |
Added assertion QName-resolution-1219000 (see |
| 20060416 | AGR |
|
| 20060416 | AGR |
|
| 20060416 | AGR |
|
| 20060415 | AGR |
|
| 20060415 | AGR | Editorial changes: Replaced wording that talked about errors with language that used keywords such as MUST and MUST NOT. |
| 20060415 | AGR |
|
| 20060309 | AGR |
Added quotes to xmlns attribute in example as reported by
|
| 20060226 | AGR | Reviewed and added assertions to sections 2. 2.1, 4, 5, 6, 7, 8 and Appendix A. |
| 20060224 | RRC | Added assertions to sections 2.2, 2.3, 2.4, 2.5, 2.6, 3. |
| 20060220 | AGR | |
| 20060109 | AGR |
Added assertions posted to mailing list:
|
| 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 Property component independent of XML Schema (issue 248). |
| 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 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: |
| 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 |