W3C

Web Services Metadata Exchange (WS-MetadataExchange)

W3C Proposed Recommendation 27 September 2011

This version:
http://www.w3.org/TR/2011/PR-ws-metadata-exchange-20110927
Latest version:
http://www.w3.org/TR/ws-metadata-exchange
Previous version:
http://www.w3.org/TR/2011/CR-ws-metadata-exchange-20110428
Editors:
Doug Davis, IBM
Ashok Malhotra, Oracle
Katy Warr, IBM
Wu Chou, Avaya

Abstract

This specification defines how metadata associated with a Web service endpoint can be represented as [WS-Transfer] resources or HTTP resources, how metadata can be embedded in [WS-Addressing] endpoint references, how metadata could be retrieved from a metadata resource, and how metadata associated with implicit features can be advertised.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

The W3C Membership and other interested parties are invited to review the document and send comments to the Working Group's public mailing list public-ws-resource-access-comments@w3.org mailing list (public archive) until 4 November 2011. See W3C mailing list and archive usage guidelines. Advisory Committee Representatives should consult their WBS questionnaires.

No substantive changes were made as a result of the Candidate Recommendation phase (see also diff, test scenario and implementation report).

A Proposed Recommendation is a specification that is under review by the W3C Advisory Committee for endorsement as a W3C Recommendation. It is is a mature document that has been widely reviewed and has been shown to be implementable. W3C encourages everybody to implement this specification.

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.

It has been produced by the Web Services Resource Access Working Group (WG), which is part of the W3C Web Services Activity.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Composable Architecture
2 Introduction
   2.1 Requirements
   2.2 Examples
3 Notations and Terminology
   3.1 Notational Conventions
   3.2 Considerations on the Use of Extensibility Points
   3.3 Terminology
   3.4 Compliance
   3.5 XML Namespaces
4 Web Services Metadata Collection
5 Metadata Resources
6 Retrieving Metadata about Service Endpoints
   6.1 GetWSDL
   6.2 GetMetadata
   6.3 PutMetadata
   6.4 DeleteMetadata
7 Metadata References
   7.1 mex:Location
   7.2 mex:Reference
   7.3 Examples
8 Metadata in Endpoint References
   8.1 Endpoint References Containing Metadata
   8.2 Associating Policies with Endpoint References
9 Exposing Metadata for Implicitly Defined Features
10 Faults
   10.1 UnsupportedMetadata
   10.2 InvalidMetadata
11 Security Considerations
   11.1 Metadata and Security Bootstrapping
12 WS-MetadataExchange Metadata
   12.1 MetadataExchange Assertion
13 Bootstrapping Metadata Retrieval
14 Acknowledgements
15 References
   15.1 Normative References

Appendices

A XML Schema
B WSDL
C Change Log


1 Composable Architecture

By using the XML, SOAP [SOAP11], [SOAP12], and WSDL [WSDL11] extensibility models, the Web service specifications (WS-*) are designed to be composed with each other to provide a rich set of tools for the Web services environment. This specification specifically relies on other Web service specifications to provide secure, reliable, and/or transacted message delivery and to express Web service and client policy.

2 Introduction

Web services use metadata to describe what other endpoints need to know to interact with them. Specifically, [WS-Policy] describes the capabilities, requirements, and general characteristics of Web services; [WSDL11] describes abstract message operations, concrete network protocols, and endpoint addresses used by Web services; XML Schema [XMLSchema - Part 1], [XMLSchema - Part 2] describes the structure and contents of XML-based messages received by and sent by Web services.

To bootstrap communication with Web services this specification defines how metadata can be treated as a HTTP resources or as [WS-Transfer] resources for retrieval purposes, how metadata can be embedded in WS-Addressing endpoint references, and how Web service endpoints can OPTIONALLY support a request-response interaction for the retrieval of metadata. When the type of metadata sought is clearly known, e.g., [WS-Policy], a requester MAY indicate that only that type is to be returned; where additional types of metadata are being used, or are expected, or when a requester needs to retrieve all of the metadata relevant to subsequent interactions with an endpoint, a requester MAY indicate that all available metadata, regardless of their types, are expected.

The mechanisms defined herein are intended for the retrieval of metadata (i.e., Web service description information) only. They are not intended to provide a general purpose query or retrieval mechanism for other types of data associated with a Web service, such as state data, properties and attribute values, etc.

2.1 Requirements

This specification intends to meet the following requirements:

  • Define a mechanism for retrieving metadata about a Web service endpoint.

  • Define an encapsulation format for metadata.

  • Treat the metadata about a Web service endpoint as [WS-Transfer] resources, or as an HTTP reachable resource.

  • Define a bootstrap mechanism for retrieving metadata.

  • Support future versions of known metadata formats.

  • Allow new metadata formats to be added.

2.2 Examples

Example 2-1 illustrates a sample GetWSDL request for the WSDL metadata document of a service.

Example 2-1: Sample GetWSDL request message
(01)  <s11:Envelope
(02)     xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03)     xmlns:wsa='http://www.w3.org/2005/08/addressing'>
(04)     xmlns:wst='http://www.w3.org/2011/03/ws-tra'>
(05)    <s11:Header>
(06)      <wsa:Action>
(07)        http://www.w3.org/2011/03/ws-mex/GetWSDL
(08)      </wsa:Action>
(09)      <wsa:To>http://services.example.org/stockquote</wsa:To>
(10)      <wsa:ReplyTo>
(11)        <wsa:Address>http://client.example.org</wsa:Address>
(12)      </wsa:ReplyTo>
(13)      <wsa:MessageID>
(14)        urn:uuid:1cec121a-82fe-41da-87e1-3b23f254f128
(15)      </wsa:MessageID>
(16)    </s11:Header>
(17)    <s11:Body>
(18)      <mex:GetWSDL/>
(19)    </s11:Body>
(20)  </s11:Envelope> 

Example 2-2 lists a sample response to the request in Example 2-1.

Example 2-2: Sample GetWSDLResponse message
(01)   <s11:Envelope
(02)      xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03)      xmlns:wsa='http://www.w3.org/2005/08/addressing'
(04)      xmlns:wsp='http://www.w3.org/ns/ws-policy'
(05)      xmlns:mex='http://www.w3.org/2011/03/ws-mex'>
(06)    <s11:Header>
(07)      <wsa:To>http://client.example.org</wsa:To>
(08)      <wsa:Action>
(09)        http://www.w3.org/2011/03/ws-mex/GetWSDLResponse
(10)      </wsa:Action>
(11)      <wsa:RelatesTo>
(12)        urn:uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9
(13)      </wsa:RelatesTo>
(14)    </s11:Header>
(15)    <s11:Body>
(16)      <mex:GetWSDLResponse>
(17)        <wsdl:definitions ...>
(18)          <!-- WSDL data removed for brevity -->
(19)        </wsdl:definitions>
(18)      </mex:GetWSDLResponse>
(19)    </s11:Body>
(20)  </s11:Envelope> 

Lines 17-19 in Example 2-2 is the WSDL of the service.

Example 2-3 illustrates a sample [WS-Transfer] Get request for a resource' s representation.

Example 2-3: Sample Get request message
(01)  <s11:Envelope
(02)     xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03)     xmlns:wsa='http://www.w3.org/2005/08/addressing'>
(04)     xmlns:wst='http://www.w3.org/2011/03/ws-tra'>
(05)    <s11:Header>
(06)      <wsa:Action>
(07)        http://www.w3.org/2011/03/ws-tra/Get
(08)      </wsa:Action>
(09)      <wsa:To>http://services.example.org/stockquote/metadata</wsa:To>
(10)      <wsa:ReplyTo>
(11)        <wsa:Address>http://client.example.org</wsa:Address>
(12)      </wsa:ReplyTo>
(13)      <wsa:MessageID>
(14)        urn:uuid:1cec121a-82fe-41da-87e1-3b23f254f128
(15)      </wsa:MessageID>
(16)    </s11:Header>
(17)    <s11:Body>
(18)      <wst:Get/>
(19)    </s11:Body>
(20)  </s11:Envelope>

The sample request message of Example 2-3 is a [WS-Transfer] request for the retrieval of a resource's representation. In this case, the requested representation is the WS-MetadataExchange Metadata element about a Web service endpoint. The fact that the resource's representation is a mex:Metadata element might be known to the requestor but is not explicitly encoded in the request message.

Example 2-4 illustrates a sample response to the request of Example 2-3.

Example 2-4: Sample response message with metadata
(01)  <s11:Envelope
(02)      xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03)      xmlns:xs='http://www.w3.org/2001/XMLSchema'
(04)      xmlns:wsa='http://www.w3.org/2005/08/addressing'
(05)      xmlns:mex='http://www.w3.org/2011/03/ws-mex'
(06)      xmlns:wsp='http://www.w3.org/ns/ws-policy'
(07)      xmlns:wst='http://www.w3.org/2011/03/ws-tra'
(08)      xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'>
(09)    <s11:Header>
(10)      <wsa:Action>
(11)        http://www.w3.org/2011/03/ws-tra/GetResponse
(12)      </wsa:Action>
(13)      <wsa:To>http://client.example.org</wsa:To>
(14)      <wsa:RelatesTo>
(15)        urn:uuid:1cec121a-82fe-41da-87e1-3b23f254f128
(16)      </wsa:RelatesTo>
(17)    </s11:Header>
(18)    <s11:Body>
(19)      <wst:GetResponse>
(20)        <mex:Metadata>
(21)          <mex:MetadataSection Dialect='wsdl:definitions'>
(22)            <wsdl:definitions>
(23)              <!-- WSDL data removed for brevity -->
(24)            </wsdl:definitions>
(25)          </mex:MetadataSection>
(26)          <mex:MetadataSection
(27)              Dialect='xs:schema'
(28)              Identifier='http://services.example.org/stockquote/schemas'>
(29)            <mex:MetadataLocation>
(30)              http://services.example.org/stockquote/schemas
(31)            </mex:MetadataLocation>
(32)          </mex:MetadataSection>
(33)          <mex:MetadataSection
(34)              Dialect='wsp:Policy'
(35)              Identifier='http://services.example.org/stockquote/policy'>
(36)            <mex:MetadataReference>
(37)              <wsa:Address>
(38)                http://services.example.org/stockquote/policy
(39)              </wsa:Address>
(40)            </mex:MetadataReference>
(41)          </mex:MetadataSection>
(42)        </mex:Metadata>
(43)      </wst:GetResponse>
(44)    </s11:Body>
(45)  </s11:Envelope>

The message of Example 2-4 is a [WS-Transfer] response message to the request of Example 2-3. The content of the [Body] (lines 18-44) is a mex:Metadata element with metadata about the Web service endpoint (lines 20-42). The mex:Metadata contains three MetadataSections. The first MetadataSection (lines 21-25) contains the [WSDL11] of the Web service endpoint. The second MetadataSection (lines 26-32) contains the location of the XML Schemas [XMLSchema - Part 1], [XMLSchema - Part 2] used by the WSDL document. The schemas can be retrieved through an HTTP GET request at the identified URL (lines 29-31). The third MetadataSection (lines 33-41) contains the [WS-Addressing] endpoint reference (lines 36-40) of a [WS-Transfer] resource the representation of which is a [WS-Policy] document as indicated by the Dialect attribute (line 34).

While the WS-Policy of the Web service endpoint could be retrieved using a WS-Transfer Get request directed to the endpoint identified by the mex:MetadataReference element in lines 36-40 of Example 2-4, some endpoints MAY support explicit requests for metadata via the GetMetadata operation. Example 2-5 illustrates a sample GetMetadata request for the [WS-Policy].

Example 2-5: Sample GetMetadata request message
(01)  <s11:Envelope
(02)      xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03)      xmlns:wsa='http://www.w3.org/2005/08/addressing'
(04)      xmlns:wsp='http://www.w3.org/ns/ws-policy'
(05)      xmlns:mex='http://www.w3.org/2011/03/ws-mex' >
(06)    <s11:Header>
(07)      <wsa:To>http://services.example.org/stockquote</wsa:To>
(08)      <wsa:Action>
(09)        http://www.w3.org/2011/03/ws-mex/GetMetadata
(10)      </wsa:Action>
(11)      <wsa:MessageID>
(12)        urn:uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9
(13)      </wsa:MessageID>
(14)      <wsa:ReplyTo>
(15)        <wsa:Address>http://client.example.org</wsa:Address>
(16)      </wsa:ReplyTo>
(17)    </s11:Header>
(18)    <s11:Body>
(19)      <mex:GetMetadata>
(20)        <mex:Dialect Type='{http://www.w3.org/ns/ws-policy}Policy'
(21)          Identifier='http://services.example.org/stockquote/policy'/>
(22)      </mex:GetMetadata>
(23)    </s11:Body>
(24)  </s11:Envelope>

Lines 8-10 in Example 2-5 indicate this is a GetMetadata request. As lines 19-22 indicate, this request is for the policy of the Web service endpoint (line 7).

Example 2-6 lists a sample response to the request in Example 2-5.

Example 2-6: Sample GetMetadataResponse message
(01)   <s11:Envelope
(02)      xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03)      xmlns:wsa='http://www.w3.org/2005/08/addressing'
(04)      xmlns:wsp='http://www.w3.org/ns/ws-policy'
(05)      xmlns:mex='http://www.w3.org/2011/03/ws-mex'>
(06)    <s11:Header>
(07)      <wsa:To>http://client.example.org</wsa:To>
(08)      <wsa:Action>
(09)        http://www.w3.org/2011/03/ws-mex/GetMetadataResponse
(10)      </wsa:Action>
(11)      <wsa:RelatesTo>
(12)        urn:uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9
(13)      </wsa:RelatesTo>
(14)    </s11:Header>
(15)    <s11:Body>
(16)      <mex:GetMetadataResponse>
(17)        <mex:Metadata>
(18)          <mex:MetadataSection
(19)              Dialect='wsp:Policy'
(20)              Identifier='http://services.example.org/stockquote/policy'>
(21)            <wsp:Policy>
(22)              <wsp:ExactlyOne>
(23)                <!-- Policy alternatives -->
(24)              </wsp:ExactlyOne>
(25)            </wsp:Policy>
(26)          </mex:MetadataSection>
(27)        </mex:Metadata>
(28)      </mex:GetMetadataResponse>
(29)    </s11:Body>
(30)  </s11:Envelope>

Lines 8-10 in Example 2-6 indicate this message is a response to a GetMetadata request, and lines 11-13 indicate that it is a response to the request in Example 2-5. Lines 17-26 contain a single MetadataSection (lines 18-26); line 19 indicates that the metadata in this section is of type, or Dialect, WS-Policy while line 20 identifies a specific policy document. Line 23 would have contained the policy expressions for the Web service endpoint to which the GetMetadata request of Example 2-5 was directed.

3 Notations and Terminology

This section specifies the notations, namespaces, and terminology used in this specification.

3.1 Notational Conventions

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 [RFC 2119].

This specification uses the following syntax to define outlines for messages:

  • The syntax appears as an XML instance, but values in italics indicate data types instead of literal values.

  • Characters are appended to elements and attributes to indicate cardinality:

    • "?" (0 or 1)

    • "*" (0 or more)

    • "+" (1 or more)

  • The character "|" is used to indicate a choice between alternatives.

  • The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.

  • The characters "[" and "]" are used to call out references and property names.

  • Ellipses (i.e., "...") indicate points of extensibility.

  • XML namespace prefixes (see Table 3-1) are used to indicate the namespace of the element being defined.

In addition to Message Information Header properties [WS-Addressing], this specification uses the following properties to define messages:

[Headers]

Unordered message headers.

[Action]

The value to be used for the wsa:Action IRI.

[Body]

A message body.

These properties bind to a SOAP Envelope as follows:

<s:Envelope>
  <s:Header>
    [Headers]
    <wsa:Action>[Action]</wsa:Action>
    ...
  </s:Header>
  <s:Body>[Body]</s:Body> 
</s:Envelope>

This specification can be used in terms of XML Information Set (Infoset) [XML Infoset], even though the specification uses XML 1.0 terminology. Valid Infoset for this specification is the one serializable in XML 1.0, hence the use of XML 1.0.

The term "generate" is used in relation to the various faults defined by this specification to imply that a fault is produced and no further processing SHOULD be performed. In these cases the fault SHOULD be transmitted. However, there might be reasons when a compliant implementation can choose not to transmit the fault - for example, security concerns - in these situations the service MAY choose not to transmit the fault.

3.2 Considerations on the Use of Extensibility Points

The elements defined in this specification MAY be extended at the points indicated by their outlines and schema. Implementations MAY add child elements and/or attributes at the indicated extension points but MUST NOT contradict the semantics of the parent and/or owner, respectively. If a receiver does not recognize an extension, the receiver SHOULD ignore that extension. Senders MAY indicate the presence of an extension that has to be understood through the use of a corresponding SOAP Header with a soap:mustUnderstand attribute with the value "1".

In cases where it is either desirable or necessary for the receiver of a request that has been extended to indicate that it has recognized and accepted the semantics associated with that extension, it is RECOMMENDED that the receiver add a corresponding extension to the response message. The definition of an extension SHOULD clearly specify how the extension that appears in the response correlates with that in the corresponding request.

Extension elements and attributes MUST NOT use the Web Services Metadata Exchange namespace URI.

3.3 Terminology

Service Endpoint

A Web service that is addressable using a WS-Addressing endpoint reference. Within the context of this specification, it is assumed that the consumer's primary goal is to interact with this service.

Metadata Resource

A specialized Web service that is addressable using either a WS-Addressing endpoint reference or a URL and whose main purpose is to expose the XML representation of a piece of metadata associated with a Service Endpoint.

While technically a single Web service can be both a 'Service Endpoint' as well as a 'Metadata Resource', for the purposes of clarifying the various expectations of these two types Web services, this specification will discuss these two concepts (or roles) as distinct entities.

3.4 Compliance

An implementation is not compliant with this specification if it fails to satisfy one or more of the MUST or REQUIRED level requirements defined herein. A SOAP Node MUST NOT use the XML namespace identifier for this specification (listed in 3.5 XML Namespaces) within SOAP Envelopes unless it is compliant with this specification.

Normative text within this specification takes precedence over the XML Schema and WSDL descriptions, which in turn take precedence over outlines, which in turn take precedence over examples.

All messages defined by this specification MUST conform to the WS-Addressing specifications and be sent to a Web service that is addressable by an EPR (see [WS-Addressing]).

Unless otherwise noted, all IRIs are absolute IRIs and IRI comparison MUST be performed according to [RFC 3987] section 5.3.1.

For any message defined by this specification, any OPTIONAL elements or attributes in the message MAY be used by senders of the message; however receivers of those messages MUST support those OPTIONAL elements and attributes, unless other behavior is explicitly defined by this specification.

Support for the GetMetadata operation by a Web service is OPTIONAL. If metadata about a Web service endpoint is referenced by a MetadataReference, which is a [WS-Addressing] endpoint reference, then the MetadataReference MUST refer to a [WS-Transfer] resource. The referred resource MAY also support other resource management and access specifications (e.g. HTTP, WS-ResourceFramework).

Implementations are expected to support both UTF-8 and UTF-16 as described in XML 1.0.

Implementations of this specification MUST conform to the corrected version of WSDL as defined by the 'WSDL Correction' sections of WS-I Basic Profile 1.2 [BP12] and WS-I Basic Profile 2.0 [BP20].

3.5 XML Namespaces

The XML namespace URI that MUST be used by implementations of this specification is:

Table 3-1 lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Table 3-1: Prefixes and XML namespaces used in this specification
Prefix XML Namespaces Specification(s)
s (Either SOAP 1.1 or 1.2) (Either SOAP 1.1 or 1.2)
s11 http://schemas.xmlsoap.org/soap/envelope/ [SOAP11]
s12 http://www.w3.org/2003/05/soap-envelope [SOAP12]
wsa http://www.w3.org/2005/08/addressing [WS-Addressing]
wsdl http://schemas.xmlsoap.org/wsdl/ [WSDL11]
wsp http://www.w3.org/ns/ws-policy [WS-Policy]
mex http://www.w3.org/2011/03/ws-mex This specification
xs http://www.w3.org/2001/XMLSchema [XMLSchema - Part 1]
wssa http://www.w3.org/2011/03/ws-sas [WS-SOAPAssertions]
wst http://www.w3.org/2011/03/ws-tra [WS-Transfer]

The working group intends to update the value of the Web Services Metadata Exchange namespace URI each time a new version of this document is published until such time that the document reaches Candidate Recommendation status. Once it has reached Candidate Recommendation status, the working group intends to maintain the value of the Web Services Metadata Exchange namespace URI that was assigned in the Candidate Recommendation unless significant changes are made that impact the implementation or break post-CR implementations of the specification. Also see http://www.w3.org/2001/tag/doc/namespaceState.html and http://www.w3.org/2005/07/13-nsuri .

4 Web Services Metadata Collection

The WS-MetadataExchange Metadata element is a collection of metadata units such as [WSDL11] definitions, [XMLSchema - Part 1] documents, [WS-Policy] expressions, etc. Each unit corresponds to metadata for a given scope, domain, or namespace. The collection of units is represented by a Metadata element, and units within the collection are represented by MetadataSection elements.

To facilitate processing, MetadataSections are tagged with a @Dialect and @Identifier of the metadata unit. To ensure scalability, a unit of metadata MAY be embedded within its MetadataSection or MAY be included by reference, either an endpoint reference [WS-Addressing] (MetadataReference) or a URL (MetadataLocation).

The outline for the Metadata element is:

<mex:Metadata ...>
  <mex:MetadataSection Dialect='xs:QName'
                       Identifier='xs:anyURI' ...>
  (
    <mex:MetadataReference ...>
      endpoint-reference-type
    </mex:MetadataReference>
    |
    <mex:MetadataLocation ...> xs:anyURI </mex:MetadataLocation>
    |
    DialectSpecificElement
  )
  </mex:MetadataSection> *
  xs:any*
</mex:Metadata>

The following describes additional constraints on the outline listed above:

/mex:Metadata

This contains one MetadataSection child for each distinct unit of metadata. When there is a large amount of metadata, the children SHOULD contain MetadataReferences or MetadataLocations instead of the actual information.

/mex:Metadata/mex:MetadataSection

This represents a single unit of metadata (e.g., a WSDL definitions, an XML Schema document) for a given scope, domain, or namespace. A MetadataSection contains exactly one child element, either the embedded XML for the metadata unit, an endpoint reference to a Metadata Resource for the metadata unit, or a URL to metadata unit.

/mex:Metadata/mex:MetadataSection/@Dialect

This REQUIRED attribute indicates the type and version of the metadata unit contained in this MetadataSection (e.g., WSDL version 1.1). This MUST be the QName of the root element of the metadata.

If there is more than one metadata unit with the same Dialect, e.g., more than one XML Schema document, including them all, one per MetadataSection, is explicitly encouraged.

Note: the QName is serialized as {namespace-uri}localName.

/mex:Metadata/mex:MetadataSection/@Dialect='{http://www.w3.org/2011/03/ws-mex}Metadata'

This Dialect value indicates that the type of the metadata contained within the MetadataSection is itself a mex:Metadata element. When the Dialect value is used in conjunction with mex:MetadataReference or mex:MetadataLocation, the Dialect value provides the ability to include metadata by reference (an endpoint reference or a URL). Example 8-2 illustrates the use of this Dialect.

/mex:Metadata/mex:MetadataSection/@Identifier

This REQUIRED attribute indicates the Identifier for the metadata unit in this MetadataSection. Identifier is an absolute IRI.

The interpretation of Identifier is Dialect-specific. If the value of the Dialect attribute of the MetadataSection is one of the values in the table below, the Identifier attribute MUST have the indicated, corresponding value. In other cases the value of the Identifier attribute is not constrained. If there is no algorithm defined for how to determine the Identifier value for a particular type of metadata, then the Identifier MUST use a value of "" (empty string).

Dialect QName @Identifier value
xs:schema xs:schema/@targetNamespace
wsdl:definitions wsdl:definitions/@targetNamespace
wsp:Policy wsp:Policy/@Name
mex:Metadata "" (empty string)

If there is more than one MetadataSection with the same identifier, e.g., more than one XML Schema in the same target namespace, including them all, one per MetadataSection, is REQUIRED.

/mex:Metadata/mex:MetadataSection/mex:MetadataReference

This is an endpoint reference to a metadata resource and is of type EndpointReferenceType as defined by [WS-Addressing]. The metadata resource MUST support the Get operation [WS-Transfer] to allow the retrieval of the metadata unit for the MetadataSection's Dialect and Identifier. When this element is present, it MUST have no element siblings.

/mex:Metadata/mex:MetadataSection/mex:MetadataLocation

This contains a URL to metadata, and the metadata MUST be retrievable from that URL using the primary access mechanism for the scheme of the URL. For example, for an HTTP URL, the metadata MUST be retrievable by sending an HTTP GET request to the URL. When this element is present, it MUST have no element siblings.

/mex:Metadata/mex:MetadataSection/DialectSpecificElement

When any element other than MetadataReference or MetadataLocation is present, the element is to be interpreted as the representation of the metadata unit associated with the MetadataSection's Dialect and Identifier.

5 Metadata Resources

A resource is referred to as a 'metadata resource' when its representation is of type mex:Metadata, as defined in 4 Web Services Metadata Collection, or any other document format (e.g. [XMLSchema - Part 1],[XMLSchema - Part 2], [WSDL11], [WS-Policy]) that is used to describe some aspect of a service.

When a metadata resource is addressable by an endpoint reference the resource's representation MUST be retrievable using the Get operation defined in [WS-Transfer] and MAY be updated as any other [WS-Transfer] resource. When the resource is addressed by a URL the resource's representation MUST be retrievable using an HTTP GET and MAY be updated as any other HTTP resource.

To retrieve the representation of a metadata resource, a requester MAY send a [WS-Transfer] Get request message to the metadata resource's endpoint reference, or it MAY send an HTTP GET to the metadata resource's IRI. These will fetch a one-time snapshot of the metadata. The metadata associated with a service endpoint MAY be available as multiple metadata resources.

The representation of a metadata resource MAY be a mex:Metadata element which MAY contain one or more mex:MetadataSection children. Each MetadataSection is identified by a specific Dialect and contains information whose format and content depend on the Dialect.

A Web service endpoint MAY have one or more associated metadata resources.

It is important to note that metadata resources are themselves services. In other words, a metadata resource can still accept GetWSDL or GetMetadata requests, but such requests would apply to the metadata about the metadata resource and not the original service that the metadata resource describes.

6 Retrieving Metadata about Service Endpoints

This specification defines two mechanism by which a requester can ask a WS-MetadataExchange compliant 'service endpoint' for its metadata: the GetWSDL operation and the GetMetadata operation.

GetWSDL provides the means to obtain a starting point for constructing the relationships between the metadata documents that apply to a service. It is useful in situations when the requester has no prior knowledge of these relationships. The GetMetadata operation is useful in cases where the requester is already aware of these relationships or when it wishes to obtain a specific metadata document.

6.1 GetWSDL

A requester MAY send a GetWSDL request message to an endpoint to retrieve the service's WSDL metadata document. This operation MUST be supported by compliant WS-MetadataExchange service endpoints. Note, the GetWSDL operation is a SOAP-based equivalent feature to the commonly supported HTTP GET targeted at an endpoint's URL appended with "?wsdl".

Through examination of this WSDL document, and by following any references within it, a requester MUST be able to retrieve any metadata needed to interact with the service. For example, the schema used by the service might be embedded within the WSDL or could be available by following a xs:import element. Likewise, as discussed in 9 Exposing Metadata for Implicitly Defined Features through the inclusion of policy assertions and nested metadata (or metadata references) within those policy assertions, a requester MUST be able to determine the set of implicit features available and any related metadata associated with those features.

The normative outline for a GetWSDL request is:

[Action]
  http://www.w3.org/2011/03/ws-mex/GetWSDL

[Body]
  <mex:GetWSDL ...>
    xs:any*
  </mex:GetWSDL> 

If the endpoint accepts a GetWSDL request, it MUST reply with a GetWSDLResponse message. The normative outline for a GetWSDLResponse is:

[Action]
  http://www.w3.org/2011/03/ws-mex/GetWSDLResponse

[Body]
  <mex:GetWSDLResponse ...>
    xs:any*
  </mex:GetWSDLResponse> 

The following describes additional, normative constraints on the outline listed above:

[Body]/mex:GetWSDLResponse/xs:any

When the GetWSDLResponse element contains any child elements, the first element MUST either be the WSDL metadata document, or a reference to the WSDL metadata document, of the endpoint. While an endpoint MAY choose to return a reference to the WSDL, it is STRONGLY RECOMMENDED that the WSDL metadata document itself be returned. If a requester would like a reference to the WSDL then it can use the GetMetadata operation specifying the appropriate Content URI.

Any extension elements MUST appear after the WSDL document/reference. The absence of any child elements indicates that the endpoint does not have any WSDL document, or additional metadata, associated with it.

[Body]/mex:GetWSDLResponse/wsdl:definitions

When present this OPTIONAL element contains the WSDL metadata document of the endpoint.

[Body]/mex:GetWSDLResponse/mex:Location

When present this OPTIONAL element contains a reference to the WSDL metadata document of the endpoint.

[Body]/mex:GetWSDLResponse/mex:Reference

When present this OPTIONAL element contains a reference to the WSDL metadata document of the endpoint.

This operation is safe; it will not result in any side effect imputable to the requester. This means that in case of an underlying protocol error that might get unnoticed, resending the same request can be done automatically.

6.2 GetMetadata

A requester MAY send a GetMetadata request message to an endpoint to retrieve the metadata associated with that endpoint. This operation MAY be supported by WS-MetadataExchange compliant service endpoints. Observe that, in the case where a service endpoint is also a [WS-Transfer] resource, the [WS-Transfer] Get operation allows requesters to retrieve the resource representation associated with that endpoint (i.e. the "data"), while the GetMetadata operation can be used to retrieve that endpoint's metadata. The normative outline for a GetMetadata request is:

[Action]
  http://www.w3.org/2011/03/ws-mex/GetMetadata

[Body]
  <mex:GetMetadata Content='xs:any' ? ...>
    <mex:Dialect Type='mex:QNameSerialization'
                 Identifier='xs:anyURI' ?
                 Content='xs:anyURI' ? .../> *
    xs:any*
  </mex:GetMetadata> 

The following describes additional, normative constraints on the outline listed above:

[Body]/mex:GetMetadata@Content

This OPTIONAL attribute, when present, specifies the default content form IRI for this request. When this attribute is not present, the default content form IRI is 'http://www.w3.org/2011/03/ws-mex/Content/Any'.

If no dialect elements are present in the request, the response MUST only include MetadataSections of the content form specified by this attribute.

If the specified content form is not available, or not known, then the response MUST include zero MetadataSections of the specified form.

This specification defines the following content form IRIs:

Content Form IRI Form
http://www.w3.org/2011/03/ws-mex/Content/EPR A MetadataReference element is returned
http://www.w3.org/2011/03/ws-mex/Content/URI A MetadataLocation element is returned
http://www.w3.org/2011/03/ws-mex/Content/Metadata The metadata is embedded
http://www.w3.org/2011/03/ws-mex/Content/Any The service is free to choose any content form
http://www.w3.org/2011/03/ws-mex/Content/All The service MUST return all available content forms
[Body]/mex:GetMetadata/mex:Dialect

When this repeating OPTIONAL element is present, the response MUST include only MetadataSections corresponding to metadata specified by the combination of the QName, Identifier and Content attributes of each of the Dialect elements. For each Dialect element if there is no metadata for that combination of attributes then the response MUST NOT include any MetadataSections for that Dialect element.

When this element is not present, the endpoint MUST return all available metadata.

[Body]/mex:GetMetadata/mex:Dialect@Type

This REQUIRED attribute specifies the Metadata Dialect. The response MUST only include MetadataSections corresponding to the Dialect specified by this QName. If the receiver does not have any MetadataSections of this indicated Dialect, the response MUST include zero MetadataSections for this QName.

Note: the QName is serialized as {namespace-uri}localName.

[Body]/mex:GetMetadata/mex:Dialect@Identifier

When this OPTIONAL attribute is present, the response MUST include only MetadataSections with the indicated identifier; if the receiver does not have any MetadataSections of the indicated identifier, the response MUST include zero MetadataSections for this QName/Identifier pair. When this attribute is not present, the implied value is any identifier. If multiple MetadataSections have the indicated Dialect and Identifier then all of them MUST be returned. Note that the absence of this attribute is not equivalent to its presence with a value of "" - which indicates a request to retrieve all metadata whose Identifier is the empty string.

[Body]/mex:GetMetadata/mex:Dialect@Content

For the dialect indicated, the response MUST include only MetadataSections of the content form specified by this attribute.

When this OPTIONAL attribute is not present, it defaults to the value of the [Body]/mex:GetMetadata@Content attribute.

If the specified content form is not available, or not known, then the response MUST include zero MetadataSections of the specified form for this QName/Identifier pair.

Subject to authorization restrictions, services MUST return all the MetadataSections corresponding to the GetMetadata request. Note that there can be multiple MetadataSections returned for any one combination of Dialect, Identifier and Content values.

If an endpoint accepts a GetMetadata request, it MUST reply with a GetMetadataResponse message. The normative outline for a GetMetadataResponse is:

[Action]
  http://www.w3.org/2011/03/ws-mex/GetMetadataResponse

[Body]
  <mex:GetMetadataResponse ...>
    <mex:Metadata ...> ... </mex:Metadata>
    xs:any*
  </mex:GetMetadataResponse>

The following describes additional, normative constraints on the outline listed above:

[Body]/mex:GetMetadataResponse/mex:Metadata

The body of the response message MUST contain one mex:Metadata element as defined in 4 Web Services Metadata Collection.

Note, in cases where the requester, through the use of @Content and/or mex:Dialect sub-elements in the GetMetadata request, has excluded all the metadata maintained by the service, this element will be empty.

This operation is safe; it will not result in any side effect imputable to the requester. This means that in case of an underlying protocol error that might get unnoticed, resending the same request can be done automatically.

6.3 PutMetadata

A requester MAY send a PutMetadata request message to an endpoint to update the metadata associated with that endpoint. This operation MAY be supported by WS-MetadataExchange compliant service endpoints. Observe that, in the case where a service endpoint is also a [WS-Transfer] resource, the [WS-Transfer] Put operation allows requesters to update the resource representation associated with that endpoint (i.e. the "data"), while the PutMetadata operation can be used to update that endpoint's metadata.

The normative outline for a PutMetadata request is:

[Action]
  http://www.w3.org/2011/03/ws-mex/PutMetadata
 
[Body]
  <mex:PutMetadata ...>
    <mex:Metadata ...> ... </mex:Metadata>
    xs:any*
  </mex:PutMetadata>

The following describes additional, normative constraints on the outline listed above:

[Body]/mex:PutMetadata

This REQUIRED element MUST have as its first child element an element that comprises the representation of the metadata that is to be replaced. Additional extension elements MAY be included after the element representing the metadata to be updated.

[Body]/mex:PutMetadata/mex:Metadata

The body of the PutMetadata message MUST contain one mex:Metadata element as defined in 4 Web Services Metadata Collection.

The mex:Metadata element contains one MetadataSection child for each distinct unit of metadata to be updated. All resource metadata (identified by the Dialect, Identifier and Content values) specified by each metadata section MUST be replaced in its entirety by the metadata specified in the PutMetadata request message; the service MUST treat the incoming MetadataSections as the complete set of metadata for the specified Dialect, Identifier and Content values and any metadata previously associated with that triplet of values MUST be removed.

If there is no Metadata associated with the resource that corresponds to a MetadataSection child contained within the mex:Metadata element, the endpoint MUST create the Metadata if the MetadataSection has a dialect that is supported by the endpoint and if the creation of the Metadata will not invalidate the endpoint.

When storing references, the endpoint MUST NOT resolve the references in an attempt to persist the actual metadata document itself.

An endpoint MUST reject a PutMetadata request if it is unable to process all of the metadata updates requested. If the dialect, identifier or content form specified in one or more MetadataSections is unsupported by the endpoint, the endpoint MUST generate a mex:UnsupportedMetadata fault. If the creation or update of the endpoint's Metadata will render the endpoint invalid (either because the metadata is of an invalid syntax for the dialect or because the metadata will cause a semantic conflict with the endpoint's definition), the endpoint MUST generate an mex:InvalidMetadata fault.

If an endpoint accepts a PutMetadata request, it MUST reply with a PutMetadataResponse message. The normative outline for a PutMetadataResponse is:

[Action]
  http://www.w3.org/2011/03/ws-mex/PutMetadataResponse
 
[Body]
  <mex:PutMetadataResponse>
    <mex:Metadata ...> ... </mex:Metadata> ?
    xs:any*
  </mex:PutMetadataResponse>

The following describes additional, normative constraints on the outline listed above:

[Body]/mex:PutMetadataResponse

This REQUIRED element, if it contains any child elements, MUST have as its first child element, a mex:Metadata element that comprises the representation of the metadata that has been updated. Additional extension elements MAY be included after the element representing the metadata updates.

As an optimization and as a service to the requester, if there are no extension elements this element SHOULD be empty if the updated representation does not differ from the representation sent in the PutMetadata request message; that is, if the service accepted the new representation (including all Metadata updates) verbatim.

Such a response (an empty mex:PutMetadataResponse) implies that the update request was successful in its entirety (assuming no intervening mutating operations are performed). A service MAY return the current representation of the resource as the child of the mex:PutMetadataResponse element even in this case, however.

[Body]/mex:PutMetadataResponse/mex:Metadata

This OPTIONAL element comprises the representation of all the metadata sections of the resource that have been updated during the PutMetadata operation.

6.4 DeleteMetadata

A requester MAY send a DeleteMetadata request message to an endpoint to delete the metadata associated with that endpoint. This operation MAY be supported by WS-MetadataExchange compliant service endpoints. Observe that, in the case where a service endpoint is also a [WS-Transfer] resource, the [WS-Transfer] Delete operation allows requesters to update the resource representation associated with that endpoint (i.e. the "data"), while the DeleteMetadata operation can be used to update that endpoint's metadata.

The normative outline for a DeleteMetadata request is:

[Action]
  http://www.w3.org/2011/03/ws-mex/DeleteMetadata
 
[Body]
  <mex:DeleteMetadata ...>
    <mex:Dialect Type='mex:QNameSerialization'
                 Identifier='xs:anyURI'? 
                 Content='xs:anyURI'? .../> +
    xs:any*
  </mex:DeleteMetadata>

The following describes additional, normative constraints on the outline listed above:

[Body]/mex:DeleteMetadata

This REQUIRED element MUST have as its first children elements one or more elements that comprise the representation of the metadata that is to be deleted. Additional extension elements MAY be included after the element representing the metadata to be deleted.

[Body]/mex:DeleteMetadata/mex:Dialect

This REQUIRED (optionally repeating) element specifies the metadata to be deleted.

[Body]/mex:DeleteMetadata/mex:Dialect@Type

This REQUIRED attribute specifies the Metadata Dialect of the metadata to be deleted.

Note: the QName is serialized as {namespace-uri}localName.

[Body]/mex:DeleteMetadata/mex:Dialect@Identifier

When this OPTIONAL attribute is present, only metadata with the indicated identifier is to be deleted. Absence of this attribute indicates that all metadata matching the specified Dialect and Content MUST be removed.

[Body]/mex:DeleteMetadata/mex:Dialect@Content

When this OPTIONAL attribute is present, only metadata of the specific content form is to be deleted. Absence of this attribute indicates that all metadata matching the specified Dialetc and Identifier MUST be removed.

An endpoint MUST reject a DeleteMetadata request if it is unable to process all of the metadata deletes requested. If the dialect, identifier or content form specified in one or more of the Dialect elements is unsupported by the endpoint, the endpoint MUST generate a mex:UnsupportedMetadata fault. If the deletion of the specified Metadata will render the endpoint invalid, the endpoint MUST generate an mex:InvalidMetadata fault. Note that an otherwise valid request that refers to metadata that does not exist is not considered an error condition. Rather, the service MUST continue as if it had successfully processed that one delete request.

If an endpoint accepts a DeleteMetadata request, it MUST reply with a DeleteMetadataResponse message. The normative outline for a DeleteMetadataResponse is:

[Action]
  http://www.w3.org/2011/03/ws-mex/DeleteMetadataResponse
 
[Body]
  <mex:DeleteMetadataResponse>
    xs:any*
  </mex:DeleteMetadataResponse>

There are no additional, normative constraints on the outline listed above.

7 Metadata References

While a service's metadata can be embedded in many different places (for example, within an EPR, or within a feature's policy assertion), it might be more convenient to include a reference to the metadata rather than include the actual metadata itself. This might be simply for brevity's sake or so the same copy of metadata can be used in many different locations without the overhead of duplicating it.

This specification defines two mechanisms by which a metadata reference can be used in place of metadata. These mechanisms do not modify any semantic meaning that might be associated with the presence of the metadata at any particular location - they are simply a syntactical alternative to embedding the referenced metadata.

7.1 mex:Location

The mex:Location element MAY be used to specify a reference to an HTTP metadata resource. A requester MAY use an HTTP GET to the indicated URL to retrieve the metadata.

The outline for the mex:Location element is:

<mex:Location URL="xs:anyURI" Type="mex:QNameSerialization" 
              Identifier="xs:anyURI" ...>
  xs:any*
<mex:Location> 

The following describes additional constraints on the outline listed above:

/mex:Location

This element contains a reference to an HTTP metadata resource.

/mex:Location@URL

This REQUIRED attribute contains the URL of an HTTP metadata resource. This resource MUST support retrieval of the metadata via an HTTP GET request.

/mex:Location@Type

This REQUIRED attribute indicates the QName of the referenced metadata. This can be used in deciding whether or not to retrieve the metadata.

Note: the QName is serialized as {namespace-uri}localName.

/mex:Location@Identifier

This REQUIRED attribute indicates the Identifier for the metadata being referenced. Identifier is an absolute IRI.

7.2 mex:Reference

The mex:Reference element MAY be used to specify a reference to a WS-Transfer metadata resource. A requester MAY use a WS-Transfer Get to the indicated EPR to retrieve the metadata

The outline for the mex:Reference element is:

<mex:Reference Type="mex:QNameSerialization" 
               Identifier="xs:anyURI" ...>
  endpoint-reference-type
<mex:Reference> 

The following describes additional constraints on the outline listed above:

/mex:Reference

This element is an endpoint reference to a metadata resource. This resource MUST support retrieval of the metadata via a WS-Transfer Get request.

/mex:Reference@Type

This REQUIRED attribute indicates the QName of the referenced metadata. This can be used in deciding whether or not to retrieve the metadata.

Note: the QName is serialized as {namespace-uri}localName.

/mex:Reference@Identifier

This REQUIRED attribute indicates the Identifier for the metadata being referenced. Identifier is an absolute IRI.

7.3 Examples

The following examples show how metadata might appear in various locations:

Example 7-1: WSDL in an Endpoint Reference
(01) <wsa:Endpoint ...>
(02)    <wsa:Address> http://example.com </wsa:Address>
(03)    <wsa:Metadata>
(04)      <wsdl:definitions>
(05)        ...
(06)      </wsdl:definitions>
(07)    </wsa:Metadata>
(08)  </wsa:Endpoint> 

Example 7-1 shows an endpoint reference with the endpoint's WSDL embedded. This saves the user of this EPR from having to retrieve the WSDL. This same endpoint reference might have been constructed by using a metadata reference instead, as shown in Example 7-2:

Example 7-2: WSDL reference in an Endpoint Reference
(01) <wsa:Endpoint ...>
(02)   <wsa:Address> http://example.com </wsa:Address>
(03)   <wsa:Metadata>
(04)     <mex:Location URL="http://example.com?wsdl"
(05)                     Type="{http://schemas.xmlsoap.org/wsdl/}definitions"
(06)                     Indentifier="..."/>
(07)   </wsa:Metadata>
(08) </wsa:Endpoint> 

Example 7-2 shows the same endpoint reference but rather than embedding the endpoint's WSDL directly in the EPR a mex:Location is used to indicate that if the user of the EPR needs the service's WSDL then it can retrieve it from the specified URL.

The following example WSDL shows how support for a particular feature might be indicated:

Example 7-3: Feature Metadata in a Policy Assertion
(01) <wsdl:definitions>
(02)   ...
(03)   <wsdl:service name="stockQuote">
(04)     <wsdl:port binding="..." name="...">
(05)       <soap:address location="http://example.com"/>
(06)     </wsdl:port>
(07)     <wsp:Policy>
(08)       <wse:EventSource>
(09)         <wse:FormatName uri="http://www.w3.org/2011/03/ws-evt/DeliveryFormats/Unwrap"/>
(10)         <wsdl:definitions>
(11)           ...
(12)           <wsdl:service ...>
(13)             ...
(14)             <wsp:Policy xmlns:wsp="..." wmlns:sp="...">
(15)               <sp:SymmetricBinding>
(16)                 <wsp:Policy>
(17)                   <sp:ProtectionToken>
(18)                     <wsp:Policy>
(19)                       <sp:SecureConversationToken ...>
(20)                         ...
(21)                       </sp:SecureConversationToken>
(22)                     </wsp:Policy>
(23)                   </sp:ProtectionToken>
(24)                 </wsp:Policy>
(25)               </sp:SymmetricBinding>
(26)             </wsp:Policy>
(27)           </service>
(28)         </wsdl:definitions>
(29)       </wse:EventSource>
(30)     </wsp:Policy>
(31)   </wsdl:service>
(32) </wsdl:definitions> 

This example shows the WSDL for a stockQuote service. As indicated on lines (08) through (29), this endpoint also acts as a WS-Eventing event source. The endpoint supports sending notification in the "Unwrapped" format - line (09). Line (10) through (28) provides the WSDL for the WS-Eventing features. In particular, lines (14) through (26) indicates that the WS-Eventing messages need to be protected using WS-SecureConversation.

This example could have also been written by using metadata references:

(01) <wsdl:definitions>
(02)   ...
(03)   <wsdl:service name="stockQuote">
(04)     <wsdl:port binding="..." name="...">
(05)       <soap:address location="http://example.com"/>
(06)     </wsdl:port>
(07)     <wsp:Policy>
(08)       <wse:EventSource>
(09)         <wse:FormatName uri="http://www.w3.org/2011/03/ws-evt/DeliveryFormats/Unwrap"/>
(10)         <mex:Location URL="http://example.com/EventingWSDL"
(11)                       Type="{http://schemas.xmlsoap.org/wsdl/}definitions"
(12)                       Identifier="..." />
(13)       </wse:EventSource>
(14)     </wsp:Policy>
(15)   </wsdl:service>
(16) </wsdl:definitions> 

In this case the embedded WS-Eventing WSDL that is supported by the stockQuote service has been replaced by a mex:Location element. The WSDL can now be retrieved via an HTTP GET to the URL specified on line (10).

8 Metadata in Endpoint References

8.1 Endpoint References Containing Metadata

The issuer of a WS-Addressing endpoint reference MAY include metadata for that service inside the endpoint reference itself. This mechanism simplifies the bootstrapping of the service interaction on the requester side by avoiding additional calls to retrieve the Web service metadata for the service endpoint.

Embedding the metadata (including a mex:Metadata element) inside an endpoint reference's wsa:Metadata element allows the issuer of the endpoint reference to include metadata by value or by reference, according to the options described in 4 Web Services Metadata Collection and 7 Metadata References. The outline of a [WS-Addressing] endpoint reference which includes Web services metadata is as follows:

<wsa:EndpointReference ...>
     <wsa:Address>xs:anyURI</wsa:Address>
     <wsa:ReferenceParameters> xs:any* </wsa:ReferenceParameters> ?
     <wsa:Metadata>
       ( <mex:Location .../> |
         <mex:Reference ...> ... </mex:Reference> |
         <mex:Metadata ...> ... </mex:Metadata> ) *
         xs:any*
     </wsa:Metadata> ?
     xs:any*
</wsa:EndpointReference>
/wsa:EndpointReference/wsa:Metadata/mex:Location

This repeating OPTIONAL element MAY appear as a direct child of the wsa:Metadata endpoint reference element.

/wsa:EndpointReference/wsa:Metadata/mex:Reference

This repeating OPTIONAL element MAY appear as a direct child of the wsa:Metadata endpoint reference element.

/wsa:EndpointReference/wsa:Metadata/mex:Metadata

This repeating OPTIONAL element MAY appear as a direct child of the wsa:Metadata endpoint reference element. Note: It MAY also be possible to combine multiple mex:Metadata elements into one mex:Metadata element, however, it is RECOMMENDED that multiple mex:Metadata elements be used.

/wsa:EndpointReference/wsa:Metadata/xs:any

This extensibility point, defined by WS-Addressing, can be used for embedding additional metadata.

In example Example 8-1, a [WS-Addressing] endpoint reference contains WSDL metadata by value that identifies the binding used to access the service endpoint:

Example 8-1: Endpoint reference with embedded WSDL metadata
(01) <wsa:EndpointReference
(02)     xmlns:wsa='http://www.w3.org/2005/08/addressing'>
(03)   <wsa:Address>http://services.example.org/stockquote</wsa:Address>
(04)   <wsa:Metadata>
(05)     <wsdl:definitions
(06)         name='StockQuote'
(07)         targetNamespace='http://services.example.org/stockquote'
(08)         xmlns:tns='http://services.example.org/stockquote'
(09)         xmlns:wsoap='http://schemas.xmlsoap.org/wsdl/soap/'
(10)         xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
(11)         xmlns:wsp='http://www.w3.org/ns/ws-policy'
(12)         xmlns:msgs='http://services.example.org/stockquote/schemas
(13)         xmlns:xs='http://www.w3.org/2001/XMLSchema'>
(14)       <wsdl:import
(15)           namespace='http://services.example.org/stockquote'
(16)           location='http://services.example.org/stockquote/schemas'/>
(17)       <wsdl:portType name='StockQuotePortType'>
(18)         <wsdl:operation name='GetLastTradePrice'>
(19)           <wsdl:input message='msgs:GetLastTradePriceInput'
(20)                       name='GetLastTradePriceInput'/>
(21)           <wsdl:output message='msgs:GetLastTradePriceOutput'
(22)                        name='GetLastTradePriceOutput'/>
(23)         </wsdl:operation>
(24)       </wsdl:portType>
(25)       <wsdl:binding name='StockQuoteBinding'
(26)             type='tns:StockQuotePortType'>
(27)         <wsp:PolicyReference
(28)             URI='http://services.example.org/stockquote/policy' />
(29)         <wsoap:binding style='document'
(30)                  transport='http://schemas.xmlsoap.org/soap/http'/>
(31)         <wsdl:operation name='GetLastTradePrice'>
(32)           <wsoap:operation soapAction='http://services.example.org/stockquote/GetLastTradePrice' />
(33)           <wsdl:input name='GetLastTradePriceInput'>
(34)             <wsoap:body use='literal'/>
(35)           </wsdl:input>
(36)           <wsdl:output name='GetLastTradePriceOutput'>
(37)             <wsoap:body use='literal'/>
(38)           </wsdl:output>
(39)         </wsdl:operation>
(40)       </wsdl:binding>
(41)       <wsdl:service name='StockQuoteService'>
(42)         <wsdl:port name='StockQuotePort'
(43)                    binding='tns:StockQuoteBinding' >
(44)           <wsoap:address
(45)                 location='http://services.example.org/stockquote'/>
(46)         </wsdl:port>
(47)       </wsdl:service>
(48)     </wsdl:definitions>
(49)   </wsa:Metadata>
(50) </wsa:EndpointReference> 

Lines 5-48 show the way the WSDL of the Web service endpoint is included 'by value'.

Example 8-2: Endpoint reference with embedded metadata about the Metadata Reference
(01) <wsa:EndpointReference ...>
(02)   <wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03)   <wsa:Metadata>
(04)     <mex:Reference Type="{http://www.w3.org/2011/03/ws-mex}Metadata" Identifier="">
(05)       <wsa:Address>
(06)         http://services.example.org/stockquote/metadata
(07)       </wsa:Address>
(08)       <wsa:Metadata>
(09)         <wsdl:definitions ...>
(10)           <!-- WS-Transfer WSDL portType plus binding -->
(11)         </wsdl:definitions>
(12)       </wsa:Metadata>
(13)     </mex:Reference>
(14)   </wsa:Metadata>
(15) </wsa:EndpointReference> 

Example 8-2 shows an example of a Web service endpoint reference in which the Metadata element contains a single mex:Reference element to a metadata resource (lines 4-13) the representation of which is mex:Metadata as hinted by the value of the Type attribute (line 4). The metadata reference contains a Metadata element (lines 8-12) which contains the necessary metadata for interacting with the metadata resource through [WS-Transfer] operations. Since the mex:Reference is an endpoint reference to a [WS-Transfer] resource, the embedded metadata includes the [WS-Transfer] WSDL portType and the necessary binding information for communicating with that resource.

Example 8-3: Endpoint reference with a reference to metadata about the Metadata Reference
(01) <wsa:EndpointReference ...>
(02)   <wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03)   <wsa:Metadata>
(04)     <mex:Reference Type='{http://www.w3.org/2011/03/ws-mex}Metadata' Identifier=''>
(05)       <wsa:Address>
(06)         http://services.example.org/stockquote/metadata
(07)       </wsa:Address>
(08)       <wsa:Metadata>
(09)         <!-- Ref to the WS-Transfer WSDL -->
(10)         <mex:Location URL='http://example.org/sq/TransferWSDL'
(11)                       Type='{http://schemas.xmlsoap.org/wsdl/}definitions' Identifier='...'/>
(12)       </wsa:Metadata>
(13)     </mex:Reference>
(14)   </wsa:Metadata>
(15) </wsa:EndpointReference> 

Example 8-3 shows an alternative way to represent Example 8-2. It shows an example of a Web service endpoint reference in which the Metadata element contains a single mex:Reference element to a metadata resource (lines 4-13) the representation of which is mex:Metadata as hinted by the value of the Type attribute (line 4). The metadata reference contains a Metadata element (lines 8-12) which contains the necessary metadata for interacting with the metadata resource through [WS-Transfer] operations. Since the mex:Reference is an endpoint reference to a [WS-Transfer] resource, the mex:Location element is a reference to the [WS-Transfer] WSDL which includes the portType and the necessary binding information for communicating with that resource.

In example Example 8-4, an endpoint reference to a service endpoint contains the metadata to allow requesters to issue a GetWSDL request against it.

Example 8-4: Endpoint reference containing Policy Attachment metadata for the GetWSDL operation
(01) <wsa:EndpointReference ...>
(02)   <wsa:Address>http://services.example.org/stockquote</wsa:Address> 
(03)   <wsa:Metadata> 
(04)     <wsp:PolicyAttachment>
(05)       <wsp:AppliesTo>                       
(06)         <!-- Following according to: http://www.w3.org/TR/ws-policy-attach/#uri-domain-expression --> 
(07)         <!-- with URI syntax from:
(08)              http://www.w3.org/TR/wsdl11elementidentifiers/ -->
(09)         <wsp:URI> 
(10)           http://www.w3.org/2011/03/ws-mex#wsdl1.PortTypeOperation(GetWSDL) 
(11)         </wsp:URI>
(12)       </wsp:AppliesTo> 
(13)       <wsp:Policy> ... </wsp:Policy>  
(14)     </wsp:PolicyAttachment>            
(15)   </wsa:Metadata>
(16) </wsa:EndpointReference> 

Example 8-4 shows an example of an endpoint reference to a service endpoint. The endpoint reference contains metadata associated with the service endpoint (lines 3-15) and the Policy metadata (lines 4-14) which contains the necessary metadata for interacting with the endpoint through WS-MetadataExchange. The metadata for the WS-MetadataExchange interaction is of policy attachment (line 4). The policy attachment (lines 4-14) defines the policy (line 13) and the GetWSDL operation to which the policy applies (lines 5-12).

Alternatively, Example 8-4 could have been written with the WS-MetadataExchange Policy Assertion embedded directly into the EPR along with the necessary Policy Assertions, as shown in Example 8-5:

Example 8-5: Endpoint reference containing the MetadataExchange policy assertion
(01) <wsa:EndpointReference ...>
(02)   <wsa:Address>http://services.example.org/stockquote</wsa:Address> 
(03)   <wsa:Metadata> 
(04)     <wsp:Policy>
(05)       <mex:MetadataExchange>
(06)         <wsp:Policy> ... </wsp:Policy>
(07)       </mex:MetadataExchange>
(08)     </wsp:Policy>
(09)   </wsa:Metadata>
(10) </wsa:EndpointReference> 

Example 8-5 shows an example of a endpoint reference to a service endpoint. The endpoint reference contains Policy metadata that can be used to properly interact with the service. In this case the Policy contains the mex:MetadataExchange Policy Assertion (lines 5-7) indicating that it supports the WS-MetadataExchange specification. Line 6 contains a Policy Assertion that further qualifies how a requester would invoke the WS-MetadataExchange operations. For example, the Policy Assertion on line 6 might contain assertions to indicate how all WS-MetadataExchange messages are to be consturcted.

8.2 Associating Policies with Endpoint References

It is desirable for components that provide EPRs to other components to be able to efficiently communicate the effective policies of the endpoints referenced by those EPRs. For example, a subscriber might wish to indicate to an event source that the notification messages sent as part of a subscription needs to be digitally signed. Although the mechanisms described in 8.1 Endpoint References Containing Metadata can be used to communicate the complete set of policies associated with an endpoint, the relationship of these policies to specific bindings, operations, or messages cannot be determined without additional information such as WSDL documents or wsp:PolicyAttachment elements.

A single wsp:Policy or wsp:PolicyReference element MAY appear as a child of the /wsa:EndpointReference/wsa:Metadata element.

<wsa:EndpointReference>
  <wsa:Address> xs:anyURI </wsa:Address>
  <wsa:ReferenceParameters> xs:any* </wsa:ReferenceParameters>
  <wsa:Metadata>
    ( <wsp:Policy ...> ... </wsp:Policy> |
      <wsp:PolicyReference ...> ... </wsp:PolicyReference> ) ?
  </wsa:Metadata>
</wsa:EndpointReference>

If multiple alternatives are desired, the operators defined in [WS-Policy] can be used to specify such alternatives within the single wsp:Policy element or the element referenced by the wsp:PolicyReference.

Policies that appear in an endpoint reference in this manner have Endpoint Policy Subject. Endpoint Policy Subject is defined as follows:

The wsp:Policy or wsp:PolicyReference element, when present, represents the capabilities and requirements of the endpoint referenced by the EPR as defined by Section 3, "Policy Model", in the [WS-Policy] specification. Policy attached to an EPR in this manner MUST be applicable to all message exchanges using the endpoint referenced by that EPR.

Example 8-6: Endpoint Reference with Associated Policy
(01) <wse:NotifyTo xmlns:wsa="http://www.w3.org/2005/08/addressing"
(02)               xmlns:wse="http://www.w3.org/2011/03/ws-evt">
(03)   <wsa:Address>http://www.example.com/EventSink/OnPriceChange</wsa:Address>
(04)   <wsa:ReferenceParameters>
(05)     ...
(06)   </wsa:ReferenceParameters>
(07)   <wsa:Metadata>
(08)     <wsp:Policy xmlns:wsp="..." wmlns:sp="...">
(09)       <sp:SymmetricBinding>
(10)         <wsp:Policy>
(11)           <sp:ProtectionToken>
(12)             <wsp:Policy>
(13)               <sp:SecureConversationToken ...>
(14)                 ...
(15)               </sp:SecureConversationToken>
(16)             </wsp:Policy>
(17)           </sp:ProtectionToken>
(18)         </wsp:Policy>
(19)       </sp:SymmetricBinding>
(20)     </wsp:Policy>
(21)   </wsa:Metadata>
(22) </wse:NotifyTo>

Example 8-6 shows a WS-Eventing NotifyTo EPR that refers to the endpoint to which an event source sends notification messages. Attached to this EPR is a Policy (lines 8-20) that indicates that WS-SecureConversation needs to be used when sending messages to this endpoint.

Note that in some cases the context in which an EPR appears might imply the version of SOAP that messages addressed to that EPR are to use. In this example, without an explicit use of the SOAP assertion, the Notifications will most likely be sent using the same version of SOAP that was used to carry the Subscribe message.

The [WS-Addressing] specification discusses caveats to the validity of Metadata information. These apply to policies contained within the wsa:Metadata element as discussed in this section.

The relationship, if any, between policies contained within the wsa:Metadata element and any other policies that might apply to the endpoint referred to by the containing EPR (e.g. policies that might appear in a WSDL document that describes one or more of the services offered by that endpoint) is not defined by this specification.

9 Exposing Metadata for Implicitly Defined Features

An endpoint MAY indicate that it supports a specific feature by including the feature's policy assertion within its WSDL. By doing so, the endpoint is indicating that feature operations are supported by that endpoint even though they are implicit and do not explicitly appear in its WSDL. An example of this is an endpoint that indicates the use of WS-Transfer [WS-Transfer] by the use of the wst:TransferResource WS-Policy [WS-Policy] assertion.

The Feature WSDL (the WSDL associated with these implicit operations) MAY appear within a Feature Policy assertion and can be annotated to indicate any endpoint specific metadata that might be needed by clients interacting with this service. For example, the WSDL can have policy assertions that indicate a particular security mechanism used to protect the feature's operations supported by this endpoint. When a Feature WSDL does not provide a concrete endpoint, the consumer MUST use the concrete aspects of the endpoint's WSDL.

An endpoint MAY choose to expose additional metadata about the feature by including the feature specific metadata within the feature's policy assertion. For example, an endpoint that also supports WS-Eventing might choose to have the following WS-Eventing Policy assertion defined:

Example 9-1: WS-Eventing EventSource Policy Assertion with Annotations
(01) <wsp:Policy>
(02)  <wse:EventSource>
(03)   <wse:FormatName
(04)     URI="http://www.w3.org/2011/03/ws-evt/DeliveryFormats/Unwrap">
(05)   </wse:FormatName>
(06)   <wsevd:EventDescriptions>
(07)    <wsevd:types>
(08)     <xs:schema targetNamespace="http://www.example.org/oceanwatch">
(09)      <xs:include
(10)       schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/>
(11)      <xs:element name="WindReport" type="ow:WindReportType"/>
(12)     </xs:schema>
(13)    </wsevd:types>
(14)    <wsevd:eventType name="WindReportEvent" element="ow:WindReport"
(15)      actionURI="http://www.example.org/oceanwatch/2003/WindReport"/>
(16)   </wsevd:EventDescriptions>
(17)   <wsp:Policy> ...security policies... </wsp:Policy>
(18)  </wse:EventSource>
(19) </wsp:Policy> 

When this policy assertion appears in a service's WSDL it indicates that the service supports WS-Eventing, it supports sending notifications using the 'Unwrap' format, and that it generates exactly one type of event - a <sq:Quote> event. The Policy Assertion on line 17 indicates that the nested policy assertions apply to the WS-Eventing operations. For example, if line 17 includes some security related assertions then the WS-Eventing operations would need to be secured using those security mechanisms.

When Feature Policy Assertions contain nested Policy Assertions (as show above in line 17), those assertions have Endpoint Policy Subject and apply to all message exchanges related to the feature.

If there were additional WS-Eventing metadata available, for example a specialized Feature WSDL document, then they would appear as a child of the wse:EventSource element as well.

The following shows the same WS-Eventing Policy Assertion from Example 9-1 with an embedded copy of the WS-Eventing WSDL. As discussed above, this WSDL might be annotated to specify additional constrains on the WS-Eventing message exchanges.

Example 9-2: Sample WS-Eventing Policy with Embedded WSDL
(01) <wsp:Policy>
(02)  <wse:EventSource>
(03)   <wse:FormatName
(04)     URI="http://www.w3.org/2011/03/ws-evt/DeliveryFormats/Unwrap">
(05)   </wse:FormatName>
(06)   <wsevd:EventDescriptions>
(07)    <wsevd:types>
(08)     <xs:schema targetNamespace="http://www.example.org/oceanwatch">
(09)      <xs:include
(10)       schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/>
(11)      <xs:element name="WindReport" type="ow:WindReportType"/>
(12)     </xs:schema>
(13)    </wsevd:types>
(14)    <wsevd:eventType name="WindReportEvent" element="ow:WindReport"
(15)      actionURI="http://www.example.org/oceanwatch/2003/WindReport"/>
(16)   </wsevd:EventDescriptions>
(17)   <wsdl:definitions> ...ws-eventing wsdl... </wsdl:definitions>
(18)  </wse:EventSource>
(19) </wsp:Polixy> 

The following shows a sample WS-Eventing wse:NotifyTo endpoint reference that might appear as part of a Subscribe request. Lines 05-08 indicate that WS-ReliableMessaging is required when sending notifications to this endpoint. The mex:Location element, lines 06-07, is a reference to the WS-ReliableMessaging WSDL that the event source will need to use when transmitting the WS-ReliableMessaging protocol messages for those notifications. For example, this WSDL might include security policy assertions or perhaps binding information that indicates there is a specific endpoint to which those protocol messages are to be sent - if it is different from the address specified on line 02.

Example 9-3: Sample EndpointReference with Embedded Policy
(01) <wse:NotifyTo>
(02)   <wsa:Address> http://example.com </wsa:Address>
(03)   <wsa:Metadata>
(04)     <wsp:Policy>
(05)       <wsrmp:RMAssertion>
(06)         <mex:Location URL='http://example.com/RMWSDL'
(07)                       Type='{http://schemas.xmlsoap.org/wsdl/}definitions' Identifier='...'/>
(08)       </wsrmp:RMAssertion>
(09)     </wsp:Policy>
(10)   </wsa:Metadata>
(11) </wse:NotifyTo> 

10 Faults

All fault messages defined in this specification MUST be sent according to the rules and usage described in [WS-Addressing 1.0 SOAP Binding] Section 6 for encoding SOAP 1.1 and SOAP 1.2 faults. The [Action] property below MUST be used for faults defined in this specification:

The definitions of faults in this section use the following properties:

[Code] The fault code.
[Subcode] The fault subcode.
[Reason] The English language reason element.
[Detail] The detail element. If absent, no detail element is defined for the fault.

The properties above bind to a SOAP 1.2 fault as follows:

<s12:Envelope>
  <s12:Header>
    <wsa:Action> [Action] </wsa:Action>
    <!-- Headers elided for brevity. -->
  </s12:Header>
  <s12:Body>
    <s12:Fault>
      <s12:Code>
        <s12:Value>[Code]</s12:Value>
        <s12:Subcode>
          <s12:Value>[Subcode]</s12:Value>
        </s12:Subcode>
      </s12:Code>
      <s12:Reason>
        <s12:Text xml:lang="en">[Reason]</s12:Text>
      </s12:Reason>
      <s12:Detail>
        [Detail]
        ...
      </s12:Detail>
    </s12:Fault>
  </s12:Body>
</s12:Envelope>

The properties bind to a SOAP 1.1 fault as follows:

<s11:Envelope>
  <s12:Header>
    <wsa:Action> [Action] </wsa:Action>
    <!-- Headers elided for brevity. -->
  </s12:Header>
  <s11:Body>
    <s11:Fault>
      <faultcode>[Subcode]</faultcode>
      <faultstring xml:lang="en">[Reason]</faultstring>
      <detail>
        [Detail]
        ...
      </detail>
    </s11:Fault>
  </s11:Body>
</s11:Envelope>

10.1 UnsupportedMetadata

This fault MUST be generated when one or more metadata dialect(s) specified on the request message are unsupported by the endpoint.

[Code]s:Sender
[Subcode]mex:UnsupportedMetadata
[Reason] The metadata specified on the request message is not supported by the endpoint
[Detail] One or more elements specifying the unsupported Metadata of the following form:
<Dialect Type='mex:QNameSerialization' Identifier='xs:anyURI'? .../> +

10.2 InvalidMetadata

This fault MUST be generated when the metadata passed on the PutMetadata request message is invalid or when the Metadata would render the endpoint invalid.

[Code]s:Sender
[Subcode]mex:InvalidMetadata
[Reason] The metadata specified is invalid for this endpoint
[Detail] The invalid metadata specified by a mex:Metadata element.
<mex:Metadata ...> ... </mex:Metadata>

11 Security Considerations

This specification considers two sets of security requirements, those of the applications that use the WS-MetadataExchange protocol and those of the protocol itself.

This specification makes no assumptions about the security requirements of the applications that use WS-MetadataExchange. However, once those requirements have been satisfied within a given operational context, the addition of WS-MetadataExchange to this operational context can not undermine the fulfillment of those requirements; the use of WS-MetadataExchange SHOULD NOT create additional attack vectors within an otherwise secure system.

The material below is not a "check list". There are many other security concerns that need to be considered when implementing or using this protocol. Implementers and users of this protocol are urged to perform a security analysis to determine their particular threat profile and the appropriate responses to those threats.

11.1 Metadata and Security Bootstrapping

There are cases in which the metadata used to describe a service might be considered sensitive information. In these cases it is advisable for services to authenticate and authorize consumers as part of the processing of any requests for this metadata. However, because the security aspects of a service (e.g. supported protocols and token formats, cipher suites, etc.) are usually described using metadata (i.e. the constructs defined by WS-SecurityPolicy), there is an obvious dilemma when attempting to protect metadata in this way. Services wishing to protect access to their metadata are advised to use the mechanisms described in 13 Bootstrapping Metadata Retrieval to advertise the security requirements for clients wishing to access metadata via the mechanisms defined in this specification.

12 WS-MetadataExchange Metadata

An endpoint MAY indicate its support of WS-MetadataExchange, or its features, by including the MetadataExchange Policy assertion within its WSDL. By doing so the endpoint is indicating that the corresponding WS-MetadataExchange operations are supported by that endpoint even though they are implicit and do not explicitly appear in its WSDL (i.e. the WS-MetadataExchange operations do not appear in the WSDL that MAY be retrievable by using a WS-MetadataExchange GetWSDL to that endpoint).

The WS-MetadataExchange WSDL containing the operations indicated by the MetadataExchange Assertion MAY be exposed by including the WSDL as a child of the MetadataExchange Policy assertion or by including a reference to it using the mex:Location or mex:Reference elements (as described in 7 Metadata References).

The WS-MetadataExchange WSDL can be annotated to indicate any endpoint specific metadata that might be needed by clients interacting with the WS-MetadataExchange operations. For example, the WSDL MAY have policy assertions that indicate a particular security mechanism used to protect the WS-MetadataExchange operations supported by this endpoint.

12.1 MetadataExchange Assertion

Services indicate support for the WS-MetadataExchange specification through the use of the Web Services Policy - Framework [WS-Policy] and Web Services Policy - Attachment [WS-PolicyAttachment] specifications.

This specification defines a policy assertion (mex:MetadataExchange). The normative outline of this assertion is:

<mex:MetadataExchange ...>
  <mex:GetMetadataSupported ...>
    <mex:MetadataExchangeDialect Type="mex:QNameSerialization" ...>
      <mex:MetadataContent URI="xs:anyURI" ...> 
        xs:any*
      </mex:MetadataContent> *
      xs:any*
    </mex:MetadataExchangeDialect> * 
    xs:any*
  </mex:GetMetadataSupported> ?
  <mex:PutMetadataSupported ...>
    <mex:MetadataExchangeDialect Type="mex:QNameSerialization" ...>
      <mex:MetadataContent URI="xs:anyURI" ...> 
        xs:any*
      </mex:MetadataContent> *
      xs:any*
    </mex:MetadataExchangeDialect> *
    xs:any*
  </mex:PutMetadataSupported> ?
  <mex:DeleteMetadataSupported ...>
    <mex:MetadataExchangeDialect Type="mex:QNameSerialization" ...>
      <mex:MetadataContent URI="xs:anyURI" ...> 
        xs:any*
      </mex:MetadataContent> *
      xs:any*
    </mex:MetadataExchangeDialect> *
    xs:any*
  </mex:DeleteMetadataSupported> ?
  xs:any*
</mex:MetadataExchange>

The following describes additional, normative constraints on the outline listed above:

/mex:MetadataExchange

This policy assertion has Endpoint Policy Subject. When present in a policy alternative, it indicates that the WS-MetadataExchange protocol MUST be used when communicating with this endpoint.

/mex:MetadataExchange/mex:GetMetadataSupported

When present, this OPTIONAL parameter indicates that the GetMetadata operation is supported by this endpoint.

/mex:MetadataExchange/mex:GetMetadataSupported/mex:MetadataExchangeDialect@Type

When present, this OPTIONAL parameter indicates support for the specified MetadataExchange Dialect QName by the GetMetadata operation.

Note: the QName is serialized as {namespace-uri}localName.

/mex:MetadataExchange/mex:GetMetadataSupported/mex:MetadataExchangeDialect/mex:MetadataContent

When present, this OPTIONAL parameter indicates support for the specified MetadataExchange content IRI by the GetMetadata operation for the dialect indicated.

/mex:MetadataExchange/mex:GetMetadataSupported/mex:MetadataExchangeDialect/mex:MetadataContent/xs:any

This extensibility point allows for additional MetadataContent specific metadata to be included within the policy assertion. Any metadata that appears is scoped to the use of the specified MetadataContent URI.

/mex:MetadataExchange/mex:GetMetadataSupported/mex:MetadataExchangeDialect/xs:any

This extensibility point allows for additional Metadata Dialect specific metadata to be included within the policy assertion. Any metadata that appears is scoped to the use of the specified Metadata Dialect QName.

/mex:MetadataExchange/mex:GetMetadataSupported/xs:any

This extensibility point allows for additional metadata specific to the GetMetadata operation to be included within the policy assertion. Any metadata that appears is scoped to the use of the GetMetadata operation.

/mex:MetadataExchange/mex:PutMetadataSupported

When present, this OPTIONAL parameter indicates that the PutMetadata operation is supported by this endpoint.

/mex:MetadataExchange/mex:PutMetadataSupported/mex:MetadataExchangeDialect@Type

When present, this OPTIONAL parameter indicates support for the specified MetadataExchange Dialect QName by the PutMetadata operation.

Note: the QName is serialized as {namespace-uri}localName.

/mex:MetadataExchange/mex:PutMetadataSupported/mex:MetadataExchangeDialect/mex:MetadataContent

When present, this OPTIONAL parameter indicates support for the specified MetadataExchange content IRI by the PutMetadata operation for the dialect indicated.

/mex:MetadataExchange/mex:PutMetadataSupported/mex:MetadataExchangeDialect/mex:MetadataContent/xs:any

This extensibility point allows for additional MetadataContent specific metadata to be included within the policy assertion. Any metadata that appears is scoped to the use of the specified MetadataContent URI.

/mex:MetadataExchange/mex:PutMetadataSupported/mex:MetadataExchangeDialect/xs:any

This extensibility point allows for additional Metadata Dialect specific metadata to be included within the policy assertion. Any metadata that appears is scoped to the use of the specified Metadata Dialect QName.

/mex:MetadataExchange/mex:PutMetadataSupported/xs:any

This extensibility point allows for additional metadata specific to the PutMetadata operation to be included within the policy assertion. Any metadata that appears is scoped to the use of the PutMetadata operation.

/mex:MetadataExchange/mex:DeleteMetadataSupported

When present, this OPTIONAL parameter indicates that the DeleteMetadata operation is supported by this endpoint.

/mex:MetadataExchange/mex:DeleteMetadataSupported/mex:MetadataExchangeDialect@Type

When present, this OPTIONAL parameter indicates support for the specified MetadataExchange Dialect QName by the DeleteMetadata operation.

Note: the QName is serialized as {namespace-uri}localName.

/mex:MetadataExchange/mex:DeleteMetadataSupported/mex:MetadataExchangeDialect/mex:MetadataContent

When present, this OPTIONAL parameter indicates support for the specified MetadataExchange content IRI by the DeleteMetadata operation for the dialect indicated.

/mex:MetadataExchange/mex:DeleteMetadataSupported/mex:MetadataExchangeDialect/mex:MetadataContent/xs:any

This extensibility point allows for additional MetadataContent specific metadata to be included within the policy assertion. Any metadata that appears is scoped to the use of the specified MetadataContent URI.

/mex:MetadataExchange/mex:DeleteMetadataSupported/mex:MetadataExchangeDialect/xs:any

This extensibility point allows for additional Metadata Dialect specific metadata to be included within the policy assertion. Any metadata that appears is scoped to the use of the specified Metadata Dialect QName.

/mex:MetadataExchange/mex:DeleteMetadataSupported/xs:any

This extensibility point allows for additional metadata specific to the DeleteMetadata operation to be included within the policy assertion. Any metadata that appears is scoped to the use of the DeleteMetadata operation.

/mex:MetadataExchange/xs:any

This extensibility point allows for additional WS-MetadataExchange specific metadata to be included within the policy assertion - e.g. WS-MetadataExchange WSDL, or nested policy assertions related to the WS-MetadataExchange message exchanges. Any metadata that appears is scoped to the operations and features of the WS-MetadataExchange specification.

13 Bootstrapping Metadata Retrieval

Although the operations described in 6 Retrieving Metadata about Service Endpoints can be used by a requester to obtain the metadata about a particular Service Endpoint, there is the 'chicken and egg' problem of how the requester knows whether or not these operations are supported in the first place. The facilities described in 8 Metadata in Endpoint References, 9 Exposing Metadata for Implicitly Defined Features, and 12 WS-MetadataExchange Metadata can be used to address this problem.

Example 13-1: Endpoint reference to a Service Endpoint that supports mex:GetWSDL
(01) <wsa:EndpointReference ...>
(02)   <wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03)   <wsa:Metadata>
(04)     <wsp:Policy>
(05)       <mex:MetadataExchange/>
(06)       <wssa:SOAP11/>
(07)     </wsp:Policy>
(08)   </wsa:Metadata>
(09) </wsa:EndpointReference> 

The policy assertion at line 05 in Example 13-1 indicates to consumers of this EPR that the GetWSDL operation is supported by the referenced Service Endpoint. The parameters described in 12 WS-MetadataExchange Metadata could be added to the policy assertion at line 05 to indicate additional capabilities such as support for the mex:GetMetadata operation. The assertion on line 06 indicates that SOAP 1.1 needs to be used when sending the GetWSDL message.

Alternatively the EPR for a Service Endpoint can contain embedded metadata or references to Metadata Resources that describe the referenced service. Example 8-1 illustrated an EPR with embedded WSDL metadata. Example 7-2 shows an EPR with a reference to a Metadata Resource. The representation of this resource (retrievable via HTTP GET) is a WSDL document that describes the service at "http://example.com". Example 8-3 illustrates a similar mechanism, except that the retrieval mechanism is WS-Transfer and the representation will be a mex:Metadata document.

Extra binding information (such as SOAP version) could either be implied by the context in which the EPR was provided or could be conveyed as in Example 13-2.

Example 13-2: Endpoint reference to a Service Endpoint that supports mex:GetWSDL
(01) <wsa:EndpointReference ...>
(02)   <wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03)   <wsa:Metadata>
(04)     <wsp:Policy>
(05)       <mex:MetadataExchange>
{06)         <wsdl:definitions ...>
(07)           <!-- Binding information -->
(08)           <wsdl:binding ...>
(09)             ...
(10)           </wsdl:binding>
(11)         </wsdl:definitions>
(12)       </mex:MetadataExchange>
(13)     </wsp:Policy>
(14)   </wsa:Metadata>
(15) </wsa:EndpointReference> 

When information about the availability of metadata is not present in an EPR, requesters can use contextual or out-of-band information to choose the mechanism most appropriate for retrieving the metadata. Furthermore, specific mechanisms for metadata retrieval can be defined by communities within the context of particular application domains.

14 Acknowledgements

This specification has been developed as a result of joint work with many individuals and teams, including: Alessio Soldano (Red Hat), Ashok Malhotra (Oracle Corp.), Asir Vedamuthu (Microsoft Corp.), Bob Freund (Hitachi, Ltd.), Bob Natale (MITRE Corp.), David Snelling (Fujitsu, Ltd.), Doug Davis (IBM), Fred Maciel (Hitachi, Ltd.), Geoff Bullen (Microsoft Corp.), Gilbert Pilz (Oracle Corp.), Greg Carpenter (Microsoft Corp.), Jeff Mischkinsky (Oracle Corp.), Katy Warr (IBM), Li Li (Avaya Communications), Mark Little (Red Hat), Martin Chapman (Oracle Corp.), Paul Fremantle (WSO2), Paul Nolan (IBM), Prasad Yendluri (Software AG), Ram Jeyaraman (Microsoft Corp.), Sreedhara Narayanaswamy (CA), Sumeet Vij (Software AG), Tom Rutt (Fujitsu, Ltd.), Vikas Varma (Software AG), Wu Chou (Avaya Communications), Yves Lafon (W3C/ERCIM).

15 References

15.1 Normative References

BP12
WS-I Profile, Basic Profile Version 1.2 , R. Chumbley, et al, Editors. Web Services Interoperability Organization (WS-I), 9 November 2010. Available at http://ws-i.org/profiles/BasicProfile-1.2-2010-11-09.html.
BP20
WS-I Profile, Basic Profile Version 2.0 , R. Chumbley, et al, Editors. Web Services Interoperability Organization (WS-I), 9 November 2010. Available at http://ws-i.org/profiles/BasicProfile-2.0-2010-11-09.html.
RFC 2119
Key words for use in RFCs to Indicate Requirement Levels , S. Bradner, Author. Internet Engineering Task Force, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.
RFC 3987
Internationalized Resource Identifiers (IRIs) , M. Duerst and M. Suignard, Authors. Internet Engineering Task Force, January 2005. Available at http://www.ietf.org/rfc/rfc3987.txt.
SOAP11
W3C Note, "Simple Object Access Protocol (SOAP) 1.1" , D. Box, et al, Editors. World Wide Web Consortium (W3C), 8 May 2000. Available at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
SOAP12
W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework" , M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielson, Editors. World Wide Web Consortium (W3C), 27 April 2007. Available at http://www.w3.org/TR/soap12-part1/.
WS-Addressing
W3C Recommendation, "Web Services Addressing 1.0 (WS-Addressing)" , M. Gudgin, M. Hadley, T. Rogers, Editors. World Wide Web Consortium (W3C), 9 May 2006. Available at http://www.w3.org/TR/ws-addr-core.
WS-Addressing 1.0 SOAP Binding
W3C Recommendation, "Web Services Addressing 1.0 - SOAP Binding" , M. Gudgin, M. Hadley, T. Rogers, Editors. World Wide Web Consortium (W3C), 9 May 2006. Available at http://www.w3.org/TR/ws-addr-soap.
WS-SOAPAssertions
W3C Working Group Draft, "Web Services SOAP Assertions (WS-SOAPAssertions) 1.0" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-soap-assertions.
WS-Policy
W3C Recommendation, "Web Services Policy (WS-Policy) 1.5 - Framework" , A. Vedamuthu, et al., Editors. World Wide Web Consortium (W3C), 4 September 2007. Available at http://www.w3.org/TR/ws-policy/.
WS-PolicyAttachment
W3C Recommendation, "Web Services Policy (WS-Policy) 1.5 - Attachment" , A. Vedamuthu, et al., Editors. World Wide Web Consortium (W3C), 4 September 2007. Available at http://www.w3.org/TR/ws-policy-attach/.
WS-Transfer
W3C Working Group Draft, "Web Services Transfer (WS-Transfer) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. Available at http://www.w3.org/TR/ws-transfer.
WSDL11
W3C Note, "Web Services Description Language (WSDL) 1.1" , E. Christensen, et al., Editors. World Wide Web Consortium (W3C), 15 March 2001 Available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
XML Infoset
W3C Recommendation, "XML Information Set (Second Edition)" , J. Cowan, R. Tobin, Editors. World Wide Web Consortium (W3C), 4 February 2004. Available at http://www.w3.org/TR/xml-infoset.
XMLSchema - Part 1
W3C Recommendation, "XML Schema Part 1: Structures (Second Edition)" , H. Thompson, et al., Editors. World Wide Web Consortium (W3C), 28 October 2004. Available at http://www.w3.org/TR/xmlschema-1/.
XMLSchema - Part 2
W3C Recommendation, "XML Schema Part 2: Datatypes (Second Edition)" , P. Biron, A. Malhotra, Editors. World Wide Web Consortium (W3C), 28 October 2004. Available at http://www.w3.org/TR/xmlschema-2/.

A XML Schema

A normative copy of the XML Schema [XMLSchema - Part 1], [XMLSchema - Part 2] description for this specification can be retrieved from the following address:

A non-normative copy of the XML schema is listed below for convenience.

<xs:schema
    targetNamespace='http://www.w3.org/2011/03/ws-mex'
    xmlns:tns='http://www.w3.org/2011/03/ws-mex'
    xmlns:wsa='http://www.w3.org/2005/08/addressing'
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    elementFormDefault='qualified'
    blockDefault='#all'>

  <xs:import
      namespace='http://www.w3.org/2005/08/addressing'
      schemaLocation='http://www.w3.org/2006/03/addressing/ws-addr.xsd'/>

  
  <xs:simpleType name='QNameSerialization'>
    <xs:restriction base='xs:string'>
      <xs:pattern value='\{.*\}.+'/>
      
    </xs:restriction>
  </xs:simpleType>

  <!-- GetWSDL request -->
  <xs:element name='GetWSDL'>
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace='##other' processContents='lax' minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <!-- GetWSDL response -->
  <xs:element name='GetWSDLResponse'>
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace='##other' processContents='lax' minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <!-- Get Metadata request -->
  <xs:element name='GetMetadata'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='tns:Dialect' minOccurs='0' maxOccurs='unbounded'/>
        <xs:any namespace='##other' processContents='lax' minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='Content' type='xs:anyURI'/>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <!-- Get Metadata response -->
  <xs:element name='GetMetadataResponse'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='tns:Metadata'/>
        <xs:any namespace='##other' processContents='lax' minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <!-- Put Metadata request -->
  <xs:element name='PutMetadata'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='tns:Metadata'/>
        <xs:any namespace='##other' processContents='lax' minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <!-- Put Metadata response -->
  <xs:element name='PutMetadataResponse'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='tns:Metadata' minOccurs='0'/>
        <xs:any namespace='##other' processContents='lax' minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <!-- Delete Metadata request -->
  <xs:element name='DeleteMetadata'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='tns:Dialect' minOccurs='0' maxOccurs='unbounded'/>
        <xs:any namespace='##other' processContents='lax' minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <!-- Delete Metadata response -->
  <xs:element name='DeleteMetadataResponse'>
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace='##other' processContents='lax' minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='Dialect'>
    <xs:complexType>
      <xs:attribute name='Type' type='tns:QNameSerialization' use='required'/>
      <xs:attribute name='Identifier' type='xs:anyURI'/>
      <xs:attribute name='Content' type='xs:anyURI'/>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <!-- Metadata -->
  <xs:element name='Metadata'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='tns:MetadataSection'
                    minOccurs='0'
                    maxOccurs='unbounded'/>
        <xs:any namespace='##other' processContents='lax'
                minOccurs='0'
                maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='MetadataSection'>
    <xs:complexType>
      <xs:choice>
        <xs:any namespace='##other' processContents='lax'/>
        <xs:element name='MetadataReference' type='wsa:EndpointReferenceType' />
        <xs:element name='MetadataLocation' type='tns:URI'/>
      </xs:choice>
      <xs:attribute name='Dialect' type='tns:QNameSerialization' use='required'/>
      <xs:attribute name='Identifier' type='xs:anyURI' use='required'/>
      <xs:anyAttribute namespace='##other' processContents='lax'/>
    </xs:complexType>
  </xs:element>

  <xs:complexType name='LocationType'>
    <xs:sequence>
      <xs:any namespace='##other' processContents='lax' minOccurs='0'
              maxOccurs='unbounded'/>
    </xs:sequence>
    <xs:attribute name='URL'  type='xs:anyURI' use='required'/>
    <xs:attribute name='Type' type='tns:QNameSerialization'  use='required'/>
    <xs:attribute name='Identifier' type='xs:anyURI' use='required'/>
    <xs:anyAttribute namespace='##other' processContents='lax'/>
  </xs:complexType>
  <xs:element name='Location' type='tns:LocationType'/>

  <xs:complexType name='ReferenceType'>
    <xs:complexContent>
      <xs:extension base='wsa:EndpointReferenceType'>
        <xs:attribute name='Type' type='tns:QNameSerialization'  use='required'/>
        <xs:attribute name='Identifier' type='xs:anyURI' use='required'/>
        <xs:anyAttribute processContents='lax'/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name='Reference' type='tns:ReferenceType'/>

  <!-- Policy -->
  <xs:complexType name='URI'>
    <xs:simpleContent>
      <xs:extension base='xs:anyURI'>
        <xs:anyAttribute namespace='##other' processContents='lax'/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:element name='MetadataExchange'>
    <xs:complexType>
      <xs:sequence>
        <xs:element name='GetMetadataSupported' minOccurs='0'>
          <xs:complexType>
            <xs:sequence>
              <xs:element name='MetadataExchangeDialect' 
                          minOccurs='0' maxOccurs='unbounded'>
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name='MetadataContent' 
                                minOccurs='0' maxOccurs='unbounded'>
                      <xs:complexType>
                        <xs:sequence>
                          <xs:any namespace='##other' processContents='lax' 
                                  minOccurs='0' maxOccurs='0'/>
                        </xs:sequence>
                        <xs:attribute name='URI' type='xs:anyURI' 
                                                 use='required' />
                        <xs:anyAttribute namespace="##other" 
                                         processContents='lax'/>
                      </xs:complexType>
                    </xs:element>
                    <xs:any namespace='##other' processContents='lax'
                            minOccurs='0' maxOccurs='unbounded'/>
                  </xs:sequence>
                  <xs:attribute name='URI' type='xs:anyURI' 
                                use='required'/>
                  <xs:anyAttribute namespace='##other' 
                                   processContents='lax'/>
                </xs:complexType>
              </xs:element>
              <xs:any namespace='##other' processContents='lax' 
                      minOccurs='0' maxOccurs='unbounded'/>
            </xs:sequence>
            <xs:anyAttribute namespace='##other' processContents='lax' />
          </xs:complexType>
        </xs:element>
        <xs:element name='PutMetadataSupported' minOccurs='0'>
          <xs:complexType>
            <xs:sequence>
              <xs:element name='MetadataExchangeDialect' 
                          minOccurs='0' maxOccurs='unbounded'>
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name='MetadataContent' 
                                minOccurs='0' maxOccurs='unbounded'>
                      <xs:complexType>
                        <xs:sequence>
                          <xs:any namespace='##other' processContents='lax' 
                                  minOccurs='0' maxOccurs='0'/>
                        </xs:sequence>
                        <xs:attribute name='URI' type='xs:anyURI' 
                                                 use='required' />
                        <xs:anyAttribute namespace="##other" 
                                         processContents='lax'/>
                      </xs:complexType>
                    </xs:element>
                    <xs:any namespace='##other' processContents='lax'
                            minOccurs='0' maxOccurs='unbounded'/>
                  </xs:sequence>
                  <xs:attribute name='URI' type='xs:anyURI' 
                                use='required'/>
                  <xs:anyAttribute namespace='##other' 
                                   processContents='lax'/>
                </xs:complexType>
              </xs:element>
              <xs:any namespace='##other' processContents='lax' 
                      minOccurs='0' maxOccurs='unbounded'/>
            </xs:sequence>
            <xs:anyAttribute namespace='##other' processContents='lax' />
          </xs:complexType>
        </xs:element>
        <xs:element name='DeleteMetadataSupported' minOccurs='0'>
          <xs:complexType>
            <xs:sequence>
              <xs:element name='MetadataExchangeDialect' 
                          minOccurs='0' maxOccurs='unbounded'>
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name='MetadataContent' 
                                minOccurs='0' maxOccurs='unbounded'>
                      <xs:complexType>
                        <xs:sequence>
                          <xs:any namespace='##other' processContents='lax' 
                                  minOccurs='0' maxOccurs='0'/>
                        </xs:sequence>
                        <xs:attribute name='URI' type='xs:anyURI' 
                                                 use='required' />
                        <xs:anyAttribute namespace="##other" 
                                         processContents='lax'/>
                      </xs:complexType>
                    </xs:element>
                    <xs:any namespace='##other' processContents='lax'
                            minOccurs='0' maxOccurs='unbounded'/>
                  </xs:sequence>
                  <xs:attribute name='URI' type='xs:anyURI' 
                                use='required'/>
                  <xs:anyAttribute namespace='##other' 
                                   processContents='lax'/>
                </xs:complexType>
              </xs:element>
              <xs:any namespace='##other' processContents='lax' 
                      minOccurs='0' maxOccurs='unbounded'/>
            </xs:sequence>
            <xs:anyAttribute namespace='##other' processContents='lax' />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>

B WSDL

A normative copy of the WSDL [WSDL11] description for this specification can be retrieved from the following address:

A non-normative copy of the WSDL description is listed below for convenience.

<wsdl:definitions
    targetNamespace='http://www.w3.org/2011/03/ws-mex'
    xmlns:tns='http://www.w3.org/2011/03/ws-mex'
    xmlns:wsa='http://www.w3.org/2005/08/addressing'
    xmlns:wsam='http://www.w3.org/2007/05/addressing/metadata'
    xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
    xmlns:xs='http://www.w3.org/2001/XMLSchema' >

  <wsdl:types>
    <xs:schema
        targetNamespace='http://www.w3.org/2011/03/ws-mex' >
      <xs:include schemaLocation='metadataexchange.xsd' />
    </xs:schema>
  </wsdl:types>

  <wsdl:message name='GetWSDLMsg'>
    <wsdl:part name='body' element='tns:GetWSDL'/>
  </wsdl:message>

  <wsdl:message name='GetWSDLResponseMsg'>
    <wsdl:part name='body' element='tns:GetWSDLResponse'/>
  </wsdl:message>

  <wsdl:message name='GetMetadataMsg' >
    <wsdl:part name='body' element='tns:GetMetadata' />
  </wsdl:message>
  <wsdl:message name='GetMetadataResponseMsg' >
    <wsdl:part name='body' element='tns:GetMetadataResponse' />
  </wsdl:message>

  <wsdl:message name='PutMetadataMsg' >
    <wsdl:part name='body' element='tns:PutMetadata' />
  </wsdl:message>
  <wsdl:message name='PutMetadataResponseMsg' >
    <wsdl:part name='body' element='tns:PutMetadataResponse' />
  </wsdl:message>

  <wsdl:message name='DeleteMetadataMsg' >
    <wsdl:part name='body' element='tns:DeleteMetadata' />
  </wsdl:message>
  <wsdl:message name='DeleteMetadataResponseMsg' >
    <wsdl:part name='body' element='tns:DeleteMetadataResponse' />
  </wsdl:message>

  <wsdl:portType name='MetadataExchange' >

    <wsdl:operation name='GetWSDL'>
      <wsdl:input
       message='tns:GetWSDLMsg'
       wsam:Action=
        'http://www.w3.org/2011/03/ws-mex/GetWSDL'/>
      <wsdl:output
       message='tns:GetWSDLResponseMsg'
       wsam:Action=
        'http://www.w3.org/2011/03/ws-mex/GetWSDLResponse'/>
    </wsdl:operation>

    <wsdl:operation name='GetMetadata' >
      <wsdl:input
       message='tns:GetMetadataMsg'
       wsam:Action=
        'http://www.w3.org/2011/03/ws-mex/GetMetadata'/>
      <wsdl:output
       message='tns:GetMetadataResponseMsg'
       wsam:Action=
        'http://www.w3.org/2011/03/ws-mex/GetMetadataResponse'/>
    </wsdl:operation>

    <wsdl:operation name='PutMetadata' >
      <wsdl:input
       message='tns:PutMetadataMsg'
       wsam:Action=
        'http://www.w3.org/2011/03/ws-mex/PutMetadata'/>
      <wsdl:output
       message='tns:PutMetadataResponseMsg'
       wsam:Action=
        'http://www.w3.org/2011/03/ws-mex/PutMetadataResponse'/>
    </wsdl:operation>

    <wsdl:operation name='DeleteMetadata' >
      <wsdl:input
       message='tns:DeleteMetadataMsg'
       wsam:Action=
        'http://www.w3.org/2011/03/ws-mex/DeleteMetadata'/>
      <wsdl:output
       message='tns:DeleteMetadataResponseMsg'
       wsam:Action=
        'http://www.w3.org/2011/03/ws-mex/DeleteMetadataResponse'/>
    </wsdl:operation>

  </wsdl:portType>

</wsdl:definitions>

C Change Log

Data Author Description
2009/03/04 DD Added resolution of issue 6391
2009/03/04 DD Added resolution of issue 6519
2009/03/04 DD Added resolution of issue 6442
2009/03/11 DD Added change log
2009/03/11 DD Added resolution of issue 6639
2009/03/11 DD Added resolution of issue 6425
2009/03/16 KW Added resolution of issue 6587
2009/03/17 KW Added resolution of issue 6405
2009/03/17 KW Added resolution of issue 6604
2009/03/18 AM Added resolution of issue 6404
2009/03/23 DD Added resolution of issue 6666
2009/03/24 DD Added resolution of issue 6648
2009/04/07 DD Added resolution of issue 6728
2009/04/22 KW Added resolution of issue 6739
2009/04/28 DD Added resolution of issue 6787
2009/05/12 DD Added resolution of issue 6433
2009/05/21 DD Added resolution of issue 6674
2009/05/27 DD Added resolution of issue 6906
2009/07/21 DD Added resolution of issue 7122
2009/07/21 DD Added resolution of issue 6500
2009/08/04 DD Added resolution of issues 6719, 6720
2009/08/06 DD Added resolution of issue 7194
2009/08/06 DD Added resolution of issue 6679
2009/08/18 DD Added resolution of issue 7206
2009/08/18 DD Added resolution of issue 7195
2009/08/25 DD Added resolution of issue 7365
2009/08/25 DD Added resolution of issue 7270
2009/09/01 DD Added resolution of issue 6702
2009/09/02 DD Added resolution of issue 6694
2009/09/02 DD Added resolution of issue 6533
2009/09/23 DD Added resolution of issue 6570
2009/10/02 DD Added resolution of issue 7426
2009/10/05 DD Added resolution of issue 6406, 6721
2009/10/13 DD Added resolution of issue 7827
2009/10/20 DD Added resolution of issue 7068
2009/10/20 DD Added resolution of issue 7207
2009/11/05 DD Added resolution of issue 7912
2009/11/06 DD Added resolution of issue 8204
2009/11/06 DD Added resolution of issue 8168
2009/11/06 DD Added resolution of issue 8199
2009/11/06 DD Added resolution of issue 8214
2009/11/06 DD Added resolution of issue 8124
2009/11/17 DD Added resolution of issue 8280
2009/12/01 DD Added resolution of issue 8291
2009/12/01 DD Added resolution of issue 8203
2009/12/01 DD Added resolution of issue 8201
2009/12/08 DD Added resolution of issue 8227
2009/12/15 DD Added resolution of issue 8200
2009/12/15 DD Added resolution of issue 8297
2009/12/15 DD Added resolution of issue 8202
2010/01/12 DD Added resolution of issue 8293
2010/01/27 DD Added resolution of issue 8294
2010/01/27 DD Added resolution of issue 8292
2010/01/27 DD Added resolution of issue 8290
2010/01/27 DD Added resolution of issue 8205
2010/01/28 DD Added resolution of issue 7728
2010/02/09 DD Added resolution of issue 8160
2010/03/09 DD Added resolution of issue 6463, 8031, 8198
2010/03/16 DD Added resolution of issue 8289
2010/03/30 DD Added resolution of issue 9031
2010/03/30 DD Added resolution of issue 9266
2010/04/20 DD Added resolution of issue 9250
2010/05/04 DD Added resolution of issue 9087
2010/05/11 DD Added resolution of issue 9570
2010/05/11 DD Added resolution of issue 9699
2010/05/11 DD Added resolution of issue 9671
2010/05/12 DD Added resolution of issue 9709
2010/08/17 DD Added resolution of issue 10339
2010/09/28 DD Added resolution of issue 10768
2010/09/28 DD Added resolution of issue 10785
2010/11/19 DD Added resolution of issue 8284
2010/12/14 DD Added resolution of issue 11189
2011/01/26 DD Added resolution of issue 11625
2011/01/26 DD Added resolution of issue 11849
2011/01/26 DD Added resolution of issue 11867
2011/02/01 DD Added resolution of issue 11850
2011/02/01 DD Added resolution of issue 11882
2011/02/07 DD Added resolution of issue 11899
2011/02/15 DD Added resolution of issue 11865
2011/02/17 DD Added resolution of issue 12113
2011/02/17 DD Added resolution of issue 11790
2011/03/22 DD Added resolution of issue 12093
2011/04/19 DD Added resolution of issue 12457
2011/07/05 DD Added resolution of issue 13148
2011/07/05 DD Added resolution of issue 13151