This document describes the Web Services Description Language (WSDL) Version 1.2, 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.
This is a
This document has been produced as part of the
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the Web Services Description Working Group.
Comments on this document are invited and are to be sent to
Patent disclosures relevant to this specification may be found on
the Working Group's
A list of
Last Modified: $Date: 2003/01/23 21:33:44 $
Web Services Description Language (WSDL) provides a model and an XML format for describing Web services. WSDL enables one to separate the description of the abstract functionality offered by a service from concrete details of a service description such as "how" and "where" that functionality is offered.
This specification defines a language for describing the abstract
functionality of a service as well as a framework for describing the
concrete details of a service description. The companion
specification,
WSDL describes Web services starting with the
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
This specification uses properties from the XML Information Set
This specification uses namespace prefixes throughout; they are
listed in
| Prefix | Namespace | Notes |
|---|---|---|
| wsdl | A normative XML Schema |
|
| soap12 | Defined by WSDL 1.2: Bindings |
|
| http | ||
| mime | ||
| xs | Defined in the W3C XML Schema
specification |
|
| xsi |
Namespace names of the general form
All parts of this specification are normative, with the exception of examples and sections explicitly marked as "Non-Normative".
This section describes the conceptual model for WSDL as a set of components with properties, each aspect of a Web service that WSDL can describe having its own property. In addition an XML Infoset representation for these components is provided, along with a mapping from that representation to the various component properties. How the XML Infoset representation of a given set of WSDL components is constructed is outside the scope of this specification.
At the abstract level, the Definitions Component is just a container for two categories of component; WSDL components and type system components. WSDL components are messages, port types, bindings and services.
Type system components are element declarations and type
definitions drawn from some type system. The former define the
[local name], [namespace name], [children] and [attributes]
properties of an
The properties of the Definitions Component are as follows:
{messages} A set of named message definitions
{port types} A set of named port type definitions
{bindings} A set of named binding definitions
{services} A set of named service definitions
{type definitions} A set of named type definitions, each one isomorphic to a simple or complex type as defined by XML Schema
{element declarations} A set of named element declarations, each one isomorphic to a global element declaration as defined by XML Schema
WSDL definitions are represented in XML by one or more WSDL
Information Sets (Infosets),
that is one or more
The
A [local name] of
A [namespace name] of
One or more
A
Zero or more namespace qualified
Zero or more
An optional
Zero or more
Zero or more
Zero or more
An optional
Zero or more
Zero or more namespace qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Definitions Component
(see
| Property | Mapping |
|---|---|
| {messages} |
The message definitions corresponding to all the
|
| {port types} |
The port type definitions corresponding to all the
|
| {bindings} |
The binding definitions corresponding to all the
|
| {services} |
The service definitions corresponding to all the
|
| {type definitions} |
The type definition components corresponding to all the
type definitions defined as descendants of the
|
| {element declarations} |
The element declaration components corresponding to all the
element declarations defined as descendants of the
|
A message component describes the abstract format of a
particular message that a Web service sends or receives.
The format of a message is typically described in terms of XML
Messages are named constructs and can be referred to by
QName (see
The properties of the Message Component are as follows:
{name} An NCName as defined by
{target namespace} A namespace name, as defined in
{parts} A set of named part definitions.
For each message component in the {messages} property of a definitions container the combination of {name} and {target namespace} properties MUST be unique.
The XML representation for a message definition component is an
A [local name] of
A [namespace name] of
One or more
A
Zero or more namespace qualified
Zero or more
An optional
Zero or more
Zero or more namespace qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Message Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {target namespace} |
The actual value of the |
| {parts} |
The set of part definitions corresponding to the
|
A part component describes a portion of a particular message
that a web service sends or receives. The format of a part is
described by reference to type definition or element declaration
components. Such components may be drawn from any appropriate
type system. However WSDL makes special recognition of the XML
Schema language
Part components are local to a given message component, they cannot be referred to by QName.
The properties of the Part Component are as follows:
{name} An NCName as defined by
{content reference} A reference to either an element declaration or a type definition component
For each part component in the {parts} property of a given message component the {name} property MUST be unique.
The XML representation for a part definition is an
A [local name] of
A [namespace name] of
Two or more
A
One of the following;
An
A
A namespace qualified
Zero or more namespace qualified
Zero or more
An optional
Zero or more namespace qualified
A part carries information about its type system by the reference contained
in the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Part Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {content reference} |
The element declaration resolved to by the value of
the |
A port type component describes a set of messages that a service sends and/or receives. It does this by grouping related messages into operations. An operation is a set of input and output messages, a port type is a set of operations.
A port type can optionally extend one or more other port types. In such cases the port type contains the operations of the port types it extends, along with any operations it defines.
Port types are named constructs and can be referred to by
QName (see
The properties of the Port Type Component are as follows:
{name} An NCName as defined by
{target namespace} A namespace name, as defined in
{extended port types} A set of named port type definitions.
{operations} A set of named port type operation definitions.
For each port type component in the {port types} property of a definitions container the combination of {name} and {target namespace} properties must be unique.
The XML representation for a port type definition component is
an
A [local name] of
A [namespace name] of
One or more
A
An optional
Zero or more namespace qualified
Zero or more
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
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Port Type Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {target namespace} |
The actual value of the |
| {extended port types} |
The set of port type definitions resolved to by the values
in the |
| {operations} |
The set of port type operation definitions corresponding to the
|
A port type operation component describes an operation that a given port type supports. An operation is a set of message references. Message references may be to messages this operation accepts, that is input messages, or messages this operation sends, that is output or fault messages.
Port type operation components are local to port type components, they cannot be refered to by QName
The properties of the Port Type Operation Component are as follows:
{name} An NCName as defined by
{message exchange pattern} One of Input-Only, Output-Only, Input-Output or Output-Input
{messages} A set of message reference components
For each port type operation component in the {operations} property of a port type component the {name} property must be unique.
In cases where, due to a port type extending one or more other port
types, two or more port type operation components have the same
value for their {name} property, then the component models of
those port type operation components MUST be equivalent (see
The following list defines the semantics of each of the possible values of the {message exchange pattern} property:
{message exchange pattern} is Input-Output. The semantics are that when the input message is sent to the service, one of the following MUST happen: the output message is generated; or one of the fault messages listed is generated instead. It is an error for both an output message and a fault message to be generated in response to the same input message.
{message exchange pattern} is Input-Only. The semantics are that when a message is sent to the service, the service consumes it but does not produce any output message. There MUST NOT be any fault messages indicated in this case.
{message exchange pattern} is Output-Input. The semantics are that the service will generate the output message and in return the input message MUST be received or one of the fault messages listed MUST be received.
{message exchange pattern} is Output-Only. The semantics are that the service will generate the output message but does not expect to receive any response message or fault messages. There MUST NOT be any fault messages indicated in this case.
The XML representation for a port type operation component is an
A [local name] of
A [namespace name] of
One or more
A
Zero or more namespace qualified
One or more
An optional
One of:
An
An
Zero or more namespace qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Port Type Operation Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {message exchange pattern} | If [children] contains an |
| {messages} |
The set of message references corresponding to the
|
A message reference component refers to a named message that forms part of an operation.
Message reference components are local to a given port type operation component, they cannot be refered to by QName
The properties of the Message Reference Component are as follows:
{name} An NCName as defined by
{variety} One of input, output or fault.
{message} A reference, by QName (see
For each message reference component in the {messages} property of a port type operation component the {name} property must be unique.
The XML representation for a message reference component is
an
A [local name] of
A [namespace name] of
Two or more
A
A
Zero or more namespace qualified
Zero or more
An optional
Zero or more namespace qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The mapping between the properties of the Message Reference Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {variety} | If the [local name] of the |
| {message} |
The message component resolved to by the value of
the |
A binding component described a concrete binding of a port type component and associated operations to a particular concrete message format and transmission protocol.
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 Binding Component are as follows:
{name} An NCName as defined by
{target namespace} A namespace name, as defined in
{port type} A named port type definition
{operations} A set of named binding operation definitions
For each binding component in the {bindings} property of a definitions container the combination of {name} and {target namespace} properties must be unique.
The XML representation for a binding component
is an
A [local name] of
A [namespace name] of
One or more
A
Zero or more namespace qualified
Zero or more
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
The
A [local name] of
A [namespace name] which has no value
The type of the
Binding extension elements are used to provide information
specific to a particular binding. The semantics of such
The mapping between the properties of the Binding Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {target namespace} |
The actual value of the |
| {port type} |
The port type definition resolved to by the actual value
of the |
| {operations} | The set of binding operation definitions corresponding
to the |
A binding operation component describes a concrete binding for a particular operation of a port type to a particular concrete message format.
Binding operation components are local to a given binding component
The properties of the Binding Operation Component are as follows:
{name} An NCName as defined by
{messages} A set of binding message reference components
For each binding operation component in the {operations} property of a binding component the {name} property must be unique.
The XML representation for a binding operation component
is an
A [local name] of
A [namespace name] of
One or more
A
Zero or more namespace qualified
Zero or more
An optional
One of;
An
An
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
Binding operation extension elements are used to provide information
specific to a particular operation in a binding. The semantics of such
The mapping between the properties of the Binding Operation Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {messages} | The set of binding message reference components corresponding
to the |
A binding message reference component describes a concrete binding for a particular message in an operation to a particular concrete message format.
Binding message reference components are local to a given binding operation component, they cannot be referred to by QName.
The properties of the Binding Message Reference Component are as follows:
{name} An NCName as defined by
{variety} One of input, output or fault
For each binding message reference component in the {messages} property of a binding operation component the {name} property must be unique.
The XML representation for a binding message reference component
is an
A [local name] of
A [namespace name] of
Zero or more
An optional
Zero or more namespace qualified
Zero or more
An optional
Zero or more namespace qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
Binding message reference extension elements are used to provide information
specific to a particular message in an operation. The semantics of such
The mapping between the properties of the Binding Message Reference Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {variety} | If the [local name] of the |
A service component describes the set of port types that a service provides and the ports they are provided over.
Service are named constructs and can be referred to by
QName (see
The properties of the Service Component are as follows:
{name} An NCName as defined by
{target namespace} A namespace name, as defined in
{port types} A set of port type components
{ports} A set of port components
For each service component in the {services} property of a definitions container the combination of {name} and {target namespace} properties must be unique.
The XML representation for a service definition component
is an
A [local name] of
A [namespace name] of
One or more
A
Zero or more namespace qualified
One or more
An optional
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 mapping between the properties of the Service Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {target namespace} |
The actual value of the |
| {port type} |
The set of port type components resolved to by the actual value
of the |
| {ports} |
The port components corresponding to the |
A port component defines the particulars of a specific end-point at which a given service is available.
Port components are local to a given service component, they cannot be referred to by QName
The properties of the Port Component are as follows:
{name} An NCName as defined by
{binding} A named binding component
For each port component in the {ports} property of a service component the {name} property must be unique.
The XML representation for a port definition component
is an
A [local name] of
A [namespace name] of
Two or more
A
A
Zero or more namespace qualified
Zero or more
An optional
Zero or more namespace qualified
The
The
A [local name] of
A [namespace name] which has no value
The type of the
The
The
A [local name] of
A [namespace name] which has no value
The type of the
Port extension elements are used to provide information
specific to a particular port in a server. The semantics of such
The mapping between the properties of the Port Component (see
| Property | Mapping |
|---|---|
| {name} | The actual value of the |
| {binding} |
The binding component resolved to by the actual value of
the |
Two components of the same type are considered equivalent if the values of the properties of one component are the same as the values of the properties in the second component.
With respect to top-level components (messages, port types, bindings and services) this effectively translates to name-based equivalence given the constraints on names. That is, given two top-level components of the same type, if the {name} properties have the same value and the {target namespace} properties have the same values then the two components are in fact, the same component.
This specification defines 4 symbol spaces, one for each top-level component type ( message, port type, binding and service ). Within a symbol space all names, that is the combination of {name} and {target namespace} properties, are unique. Between symbol spaces, the combination of these two properties need not be unique. Thus it is perfectly coherent to have, for example, a binding and a port type that have the same name.
When XML Schema is being used as one of the type systems for a
WSDL description, then 6 other symbol spaces also exist, one for
each of global element declarations, global attribute
declarations, named model groups, named attribute groups, type
definitions and key constraints, as defined by
In its serialized form WSDL makes significant use of references between components. Such references are made using the Qualified Name, or QName of the component being referred to. QNames are a tuple, consisting of two parts; a namespace name and a local name. For example, in the case of a port type component, the namespace name is represented by the {namespace name} property and the local name is represented by the {name} property.
QName references are
resolved by looking in the appropriate property of the definitions
component. For example, to resolve a QName of a port type ( as
refered to by the
If the appropriate property of the definitions component does not contains a component with the required QName then the reference is a broken reference, it cannot be resolved.
At the abstract level, the Types Component is a container for imported and
embedded schema components. By design, WSDL supports any schema language
for which the syntax and semantics of import or embed have been defined.
Support for the W3C XML Schema Description Language
The schemas defined or referenced in the Types Component provide the
type system used for message parts. Message parts indicate their
structure and content by using the standard
The
A [local name] of
A [namespace name] of
Zero or more namespace qualified
Zero or more
An optional
Zero or more
Other namespace qualified
XML Schema MAY be used as the schema language, via import or embedding. Each
method defines a different
Importing an XML Schema uses the
A [local name] of
A [namespace name] of
One or two
A
An optional
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] that has no value.
The type of the
Embedding an XML schema uses the existing top-level
A [local name] of schema.
A [namespace name] of
A
Additional
Child
The
A [local name] of targetNamespace.
A [namespace name] that has no value.
The type of the
Whether embedded or imported, the type and element definitions present in a schema may be referenced from a message part.
A named, global
A named, global
Since it is unreasonable to expect that a single schema language can be used
to describe all possible message parts and their constraints, WSDL allows
alternate schema languages to be specified via extensibility elements. An
extensibility
This specification provides two mechanisms, described in this section, for modularizing WSDL descriptions. These mechanisms help to make WSDL descriptions clearer by allowing separation of the various components of a description. Such separation could be performed according to the level of abstraction of a given set of components, or according to the namespace affiliation required of a given set of components or according to some other grouping such as application applicability.
Both mechanisms work at the level of WSDL components and NOT at the level of XML Information Sets or XML 1.0 serializations.
The WSDL
The WSDL
The
A [local name] of
A [namespace name] of
An A [local name] of A [namespace name] which has no value.
The actual value of the
The WSDL
The WSDL
The
A [local name] of
A [namespace name] of
An
A [local name] of
A [namespace name] which has no value.
The
An OPTIONAL
A [local name] of
A [namespace name] which has no value.
The
The
WSDL uses the optional
The
A [local name] of
A [namespace name] of
Zero or more
Zero or more child
Zero or more
The schema for WSDL has two extensibility models, one based on element substitution groups and another based on qualified attributes.
WSDL allows extensions to be defined in terms of
It is expected that extensions will want to add to the
existing properties of components in the component model. The
specification for an extension
The WSDL schema also defines a base type for use by extensibility
elements.
Extensibility elements are commonly used to specify some technology specific binding. They allow innovation in the area of network and message protocols without having to revise the base WSDL specification. WSDL recommends that specifications defining such protocols also define any necessary WSDL extensions used to describe those protocols or formats.
An extension element is said to be
| Element name | Allowed in [children] property of | Notes |
|---|---|---|
| globalExt |
|
This |
| msgAndportTypeExt |
|
This |
| msgportTypeAndBindingExt |
|
This |
| msgportTypeBindingServiceExt |
|
This |
| bindingAndServiceExt |
|
This |
| preImportInclude |
|
This |
| inImportInclude |
|
This |
| preTypes |
|
This |
| postTypes |
|
This |
| Abstract elements related to message | ||
| msgExt |
|
This |
| msgPrePartExt |
|
This |
| msgPostPartExt |
|
This |
| msgPartExt |
|
This |
| Abstract elements related to portType | ||
| portTypeExt |
|
This |
| portTypePreOpExt |
|
This |
| portTypePostOpExt |
|
This |
| portTypeOpExt |
|
This |
| portTypeOpMsgExt |
|
This |
| portTypeOpFaultExt |
|
This |
| Abstract elements related to bindings | ||
| bindingExt |
|
This |
| bindingPreOpExt |
|
This |
| bindingPostOpExt |
|
This |
| bindingOpExt |
|
This |
| bindingOpMsgExt |
|
This |
| bindingOpFaultExt |
|
This |
| Abstract elements related to service | ||
| serviceExt |
|
This |
| servicePrePortExt |
|
This |
| servicePostPortExt |
|
This |
| portExt |
|
This |
Extension elements can be marked as mandatory by annotating them
with a
WSDL provides a global
A [local name] of
A [namespace name] of
A [specified] property with a value of
The type of the
WSDL allows qualified
WSDL does not provide a mechanism for marking extension
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 (Part 1) and
No known applications currently use this media type.
WSDL documents are not required or expected to be stored as files.
Identical to that of
As specified in
TEXT
@@@ <@@@@>
COMMON
The WSDL 1.2 specification set is a work product of the World Wide
Web Consortium's
This media type uses the
This document is the work of the W3C Web Service Description Working Group.
Members of the Working Group are (at the time of writing, and by
alphabetical order): Adi Sakala (IONA Technologies),
Allen Brookes (Rogue Wave Softwave),
Amelia Lewis (TIBCO/Extensibility),
Arthur Ryman (IBM),
Barbara Zengler (DaimlerChrysler Research and Technology),
Dale Moberg (Cyclone Commerce),
Dan Kulp (IONA Technologies),
Daniel Schutzer (Citigroup),
Dave Solo (Citigroup),
David Booth (W3C),
Dietmar Gaertner (Software AG),
Don Mullen (TIBCO Software),
Erik Ackerman (Lexmark),
Glen Daniels (Macromedia),
Igor Sedukhin (Computer Associates),
Jacek Kopecky (Systinet),
Jean-Jacques Moreau (Canon),
Jeff Mischkinsky (Oracle Corporation),
Jeffrey Schlimmer (Microsoft Corporation),
Jerry Thrasher (Lexmark),
Johan Pauhlsson (L'Échangeur),
Jonathan Marsh (
Previous members were: Aaron Skonnard (DevelopMentor), Don Wright (Lexmark), Jochen Ruetschlin (DaimlerChrysler Research and Technology), Joyce Yang (Oracle Corporation), Keith Ballinger (Microsoft), Krishna Sankar (Cisco Systems), Mario Jeckle (DaimlerChrysler Research and Technology), Pallavi Malu (Intel Corporation)
The people who have contributed to discussions on
This section will attempt to document some of the migration concerns of going from WSDL 1.1 to WSDL 1.2. We do not claim that all migration problems will be addressed here.
WSDL 1.1 supported operation overloading and WSDL 1.2 removes it. This section will provide some rationale for it and provide hints on how to work around some scenarios.
We now have portType inheritance.
A DTD may be used as the schema language for WSDL. It may not be embedded;
it must be imported. A namespace must be assigned. DTD types may be
referenced only by the
The prefix, dtd, used throughout the following is mapped to the
namespace URI
The
A [local name] of import.
A [namespace name] of "http://www.example.org/dtd".
One or two
A
An optional
The
A [local name] of namespace.
A [namespace name] that has no value.
The type of the
The WSDL author should ensure that a prefix is associated with the namespace at the proper scope (probably document scope).
The
A [local name] of location.
A [namespace name] that has no value.
The type of the
In referring to an element definition (<!ELEMENT>) from a message part, the
Note that this pattern does not attempt to make DTDs namespace-aware. It applies namespaces externally, in the import phase.
A RELAX NG schema may be used as the schema language for WSDL. It may be
embedded or imported; import is preferred. A namespace must be specified;
if an imported schema specifies one, then the [actual value] of the
Importing a RELAX NG schema uses the rng:include mechanism defined by RNG,
with restrictions on its syntax and semantics. A child
A [local name] of include.
A [namespace name] of "http://www.relaxng.org/ns/structure/1.0".
Two
A
A
Additional
Note that WSDL restricts the
The
A [local name] of ns.
A [namespace name] which has no value.
The type of the
The
A [local name] of href.
A [namespace name] that has no value.
The type of the
Embedding an RNG schema uses the existing top-level
A [local name] of grammar.
A [namespace name] of "http://www.relaxng.org/ns/structure/1.0".
An
Additional
Child
The
A [local name] of ns.
A [namespace name] that has no value.
The type of the
Whether embedded or imported, the type and element definitions present in a schema may be referenced from a message part.
A named rng:define definition may be referenced from the
A named Relax NG element definition may be referenced from the
| Date | Author | Description |
|---|---|---|
| 20030123 | JJM | Change name of {variety} property to {message exchange pattern} |
| 20030122 | MJG | Added some <emph>, <el>, <att>, &AII;, &EII;, <el> markup |
| 20030120 | MJG | Incorporated Relax NG section from Amy's types proposal |
| 20030120 | MJG | Incorporated DTD section from Amy's types proposal |
| 2003020 | MJG | Incorporated Amy's types proposal except annexes |
| 20030118 | MJG | Made some changes related to extensibility |
| 20030118 | MJG | Amended content model for operation to disallow fault element children in the input-only and output-only cases |
| 20030118 | MJG | Removed {extension} properties from binding components and port components. Added text relating to how extension elements are expected to annotate the component model. |
| 20030117 | MJG | Made further edits related to extensibility model now using substitution groups |
| 20030117 | MJG | Added initial draft of section on QName resolution |
| 20030117 | MJG | Reworked section on extensibility |
| 20030116 | MJG | Added text regarding multiple operations with the same {name} in a single port type |
| 20030116 | MJG | Added section on symbol spaces |
| 20030116 | MJG | Removed various ednotes |
| 20030116 | MJG | Added section on component equivalence |
| 20030116 | MJG | More work on include and import |
| 20021201 | MJG | Did some work on wsdl:include |
| 20021127 | MJG | Added placeholder for wsdl:include |
| 20021127 | MJG | Cleaned up language concerning |
| 20021127 | MJG | changed the language regarding extensibility elements in
|
| 20021127 | MJG | Moved all issues into issues document ( ../issues/wsd-issues.xml ) |
| 20021127 | MJG | Removed name attribute from definitions element |
| 20021127 | MJG | Removed 'pseudo-schema' |
| 20021121 | JJM | Updated media type draft appendix ednote to match minutes. |
| 20021111 | SW | Added appendix to record migration issues. |
| 20021107 | JJM | Incorporated and started adapting SOAP's media type draft appendix. |
| 20021010 | MJG | Added port type extensions, removed service type. |
| 20020910 | MJG | Removed parameterOrder from spec, as decided at September 2002 FTF |
| 20020908 | MJG | Updated parameterOrder description, fixed some spelling errors and other types. Added ednote to discussion of message parts |
| 20020715 | MJG | AM Rewrite |
| 20020627 | JJM | Changed a few remaining <emph> to either <att> or <el>, depending on context. |
| 20020627 | SW | Converted portType stuff to be infoset based and improved doc structure more. |
| 20020627 | SW | Converted message stuff to be infoset based and improved doc structure more. |
| 20020625 | SW | Mods to take into account JJM comments. |
| 20020624 | JJM | Fixed spec so markup validates. |
| 20020624 | JJM | Upgraded the stylesheet and DTD |
| 20020624 | JJM | Added sections for references and change log. |
| 20020624 | JJM | Removed Jeffrey from authors :-( Added Gudge :-) |
| 20020620 | SW | Started adding abstract model |
| 20020406 | SW | Created document from WSDL 1.1 |