This version:

One way to express bounded rationality of a player in a game theoretic models is by specifying a set of feasible strategies for that player. In dynamic game models with finite automata and bounded recall strategies, for example, feasibility of strategies is determined via certain complexity measures: the number of states of automata and the length of recall. Typically in these models, a fixed finite bound on the complexity is imposed resulting in finite sets of feasible strategies. As a consequence, the number of distinct feasible strategies in any subgame is finite. Also, the number of distinct strategies induced in the first T stages is bounded by a constant that is independent of T . In this paper, we initiate an investigation into a notion of feasibility that reflects varying degree of bounded rationality over time. Such concept must entail properties of a strategy, or a set of strategies, that depend on time. Specifically, we associate to each subset Ψi of the full (theoretically possible) strategy set a function ψi from the set of positive integers to itself. The value ψi(t) represents the number of strategies in Ψi that are distinguishable in the first t stages. The set Ψi may contain infinitely many strategies, but it can differ from the fully rational case in the way ψi grows reflecting a broad implication of bounded rationality that may be alleviated, or intensified, over time. We examine how the growth rate of ψi affects equilibrium outcomes of repeated games. In particular, we derive an upper bound on the individually rational payoff of repeated games where player 1, with a feasible strategy set Ψ1, plays against a fully rational player 2. We will show that the derived bound is tight in that a specific, and simple, set Ψ1 exists that achieves the upper bound. As a special case, we study repeated games with non-stationary bounded recall strategies where the length of recall is allowed to vary in the course of the game. We will show that a player with bounded recall can guarantee the minimax payoff of the stage game even against a player with full recall so long as he can remember, at stage t, at least K log t stages back for some constant K > 0. Thus, in order to guarantee the minimax payoff, it suffices to remember only a vanishing fraction of the past. A version of the folk theorem is provided for this class of games. (Journal of Economic Literature Classification Number:)

This is the second W3C Last Call Working Draft of Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. It has been produced by the Web Services Description Working Group, which is part of the W3C Web Services Activity. If the feedback is positive, the Working Group plans to submit this specification for consideration as a W3C Candidate Recommendation.
This Working Draft addresses all the comments received during the first Last Call review period on the WSDL 2.0 drafts. Another Last Call Working Draft is being published as substantive changes were made to the documents as a result of this review. The detailed disposition of the comments received can be found in the first Last Call issues list.
Comments on this document are to be sent to the public public-ws-desc-comments@w3.org mailing list (public archive) until 19 September 2005.
A diff-marked version against the previous version of this document is available. For a detailed list of changes since the last publication of this document, please refer to appendix E. Part 1 Change Log [p.104] . Issues about this document are documented in the new Last Call issues list maintained by the Working Group. A list of formal objections against the set of WSDL 2.0 Working Drafts is also available.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document has been produced under the 24 January 2002 Current Patent Practice as amended by the W3C Patent Policy Transition Procedure. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

Introduction
Web Services Description Language Version 2.0 (WSDL 2.0) provides a model and an XML format for describing Web services. WSDL 2.0 enables one to separate the description of the abstract functionality offered by a service from concrete details of a service description such as "how" and "where" that functionality is offered.
This specification defines a language for describing the abstract functionality of a service as well as a framework for describing the concrete details of a service description. It also defines the conformance criteria for documents in this language. The WSDL Version 2.0 Part 2: Adjuncts specification [WSDL 2.0 Adjuncts [p.89] ] describes extensions for Message Exchange Patterns, features, SOAP modules and bindings of features, and a language for describing such concrete details for SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework [p.90] ] and HTTP [IETF RFC 2616 [p.90] ]. WSDL 2.0 describes a Web service in two fundamental stages: one abstract and one concrete. Within each stage, the description uses a number of constructs to promote reusability of the description and to separate independent design concerns.

Web Service
At an abstract level, WSDL 2.0 describes a Web service in terms of the messages it sends and receives; messages are described independent of a specific wire format using a type system, typically XML Schema.
An operation associates a message exchange pattern with one or more messages. A message exchange pattern identifies the sequence and cardinality of messages sent and/or received as well as who they are logically sent to and/or received from. An interface groups together operations without any commitment to transport or wire format.
At a concrete level, a binding specifies transport and wire format details for one or more interfaces. An endpoint associates a network address with a binding. And finally, a service groups together endpoints that implement a common interface.

Document Conformance
An element information item (as defined in [XML Information Set [p.89] ]) whose namespace name is "http://www.w3.org/2005/08/wsdl" and whose local part is description conforms to this specification if it is valid according to the XML Schema for that element as defined by this specification (http://www.w3.org/2005/08/wsdl/wsdl20.xsd) and additionally adheres to all the constraints contained in this specification family and conforms to the specifications of any extensions contained in it. Such a conformant element information item constitutes a WSDL 2.0 document.
The definition of the WSDL 2.0 language is based on the XML Information Set [XML Information Set [p.89] ] but also imposes many semantic constraints over and above structural conformance to this XML Infoset. In order to precisely describe these constraints, and as an aid in precisely defining the meaning of each WSDL 2.0 document, the WSDL 2.0 specification defines a component model 2. Component Model [p.11] as an additional layer of abstraction above the XML Infoset. Constraints and meaning are defined in terms of this component model, and the definition of each component includes a mapping that specifies how values in the component model are derived from corresponding items in the XML Infoset.
An XML 1.0 document that is valid with respect to the WSDL 2.0 XML Schema and that maps to a valid WSDL 2.0 Component Model is conformant to the WSDL 2.0 specification.

The Meaning of a Service Description
A WSDL 2.0 service description indicates how potential clients are intended to interact with the described service. It represents an assertion that the described service fully implements and conforms to what the WSDL 2.0 document describes. For example, as further explained in section 6.1.1 Mandatory extensions [p.82] , if the WSDL 2.0 document specifies a particular optional extension, the functionality implied by that extension is only optional to the client. But it needs to be supported by the Web service.
A WSDL 2.0 interface describes potential interaction with a service--not required interaction. The declaration of an operation in a WSDL 2.0 interface is not an assertion that the interaction described by the operation must occur. Rather it is an assertion that if such an interaction is (somehow) initiated, then the declared operation describes how that interaction is intended to occur.

Terms Used in This Specification
This section describes the terms and concepts introduced in Part 1 of the WSDL Version 2.0 specification (this document).

Actual Value
As in [XML Schema: Structures [p.89] ], the phrase actual value is used to refer to the member of the value space of the simple type definition associated with an attribute information item which corresponds to its normalized value. This will often be a string, but may also be an integer, a boolean, a IRI reference, etc.

Inlined Schema
An XML schema that is defined in the xs:types element information item of a WSDL 2.0 description. For example, an XML Schema defined in an xs:schema element information item 3.1.2 Inlining XML Schema [p.74] .

XML Information Set Properties
This specification refers to properties in the XML Information Set [XML Information Set [p.89] ]. Such properties are denoted by square brackets, e.g. [children], [attributes].

WSDL 2.0 Component Model Properties
This specification defines and refers to properties in the WSDL 2.0 Component Model 2. Component Model [p.11] . Such properties are denoted by curly brackets, e.g. {name [p.17] }, {interfaces [p.13] }. This specification uses a consistent naming convention for component model properties that refer to components. If a property refers to a required or optional component, then the property name is the same as the component name. If a property refers to a set of components, then the property name is the pluralized form of the component name.

Z Notation
Z Notation [Z Notation Reference Manual [p.91] ] was used in the development of this specification. Z Notation is a formal specification language that is based on standard mathematical notation. The Z Notation for this specification has been verified using the Fuzz 2000 type-checker [Fuzz 2000 [p.91] ].
Since Z Notation is not widely known, it is not included the normative version of this specification. However, it is included in a non-normative version which allows to dynamically hide and show the Z Notation. Browsers correctly display the mathematical Unicode characters, provided that the required fonts are installed. Mathematical fonts for Mozilla Firefox can be downloaded from the Mozilla Web site.
The Z Notation was used to improve the quality of the normative text that defines the Component Model, and to help ensure that the test suite covered all important rules implied by the Component Model. However, the Z Notation is non-normative, so any conflict between it and the normative text is an error in the Z Notation. Readers and implementors may nevertheless find the Z Notation useful in cases where the normative text is unclear.
There are two elements of Z Notation syntax that conflict with the notational conventions described in the preceeding sections. In Z Notation, square brackets are used to introduce basic sets, e.g. [ID], which conflicts with the use of square brackets to denote XML Information Set properties 1.4.5 XML Information Set Properties [p.10] . Also, in Z Notation, curly brackets are used to denote set display and set comprehension, e.g. {1, 2, 3}, which conflicts with the use of curly brackets to denote WSDL 2.0 Component Model properties 1.4.6 WSDL 2.0 Component Model Properties [p.10] . However, the intended meaning of square and curly brackets should be clear from their context and this minor notational conflict should not cause any confusion.

BNF Pseudo-Schemas
Pseudo-schemas are provided for each component, before the description of the component. They use BNF-style conventions for attributes and elements: "?" denotes optionality (i.e. zero or one occurrences), "*" denotes zero or more occurrences, "+" one or more occurrences, " [" and "]" are used to form groups, and "|" represents choice. Attributes are conventionally assigned a value which corresponds to their type, as defined in the normative schema. Elements with simple content are conventionally assigned a value which corresponds to the type of their content, as defined in the normative schema.

Component Model
This section describes the conceptual model of WSDL 2.0 as a set of components with attached properties, which collectively describe a Web service. This model is called the Component Model of WSDL 2.0.
Components are typed collections of properties that correspond to different aspects of Web services. Each subsection herein describes a different type of component, its defined properties, and its representation as an XML Infoset [XML Information Set [p.89] ].
Properties are unordered and unique with respect to the component they are associated with. Individual properties' definitions may constrain their content (e.g., to a typed value, another component, or a set of typed values or components), and components may require the presence of a property to be considered conformant. Such properties are marked as REQUIRED, whereas those that are not required to be present are marked as OPTIONAL. By convention, when specifying the mapping rules from the XML Infoset representation of a component to the component itself, an optional property that is absent in the component in question is described as being "empty". Unless otherwise specified, when a property is identified as being a collection (a set or a list), its value may be a 0-element (empty) collection. In order to simplify the presentation of the rules that deal with sets of components, for all OPTIONAL properties whose type is a set, the absence of such a property from a component MUST be treated as semantically equivalent to the presence of a property with the same name and whose value is the empty set. In other words, every OPTIONAL set-valued property MUST be assumed to have the empty set as its default value, to be used in case the property is absent.
Component definitions are serializable in XML 1.0 format but are independent of any particular serialization of the component model. Component definitions use a subset (see 2.16 XML Schema 1.0 Simple Types Used in the Component Model [p.68] ) of the simple types defined by the XML Schema 1.0 specification [XML Schema: Datatypes [p.89] ].
In addition to the direct XML Infoset representation described here, the component model allows components external to the Infoset through the mechanisms described in 4. Modularizing WSDL 2.0 descriptions [p.77] .
A component model can be extracted from a given XML Infoset which conforms to the XML Schema for WSDL 2.0 by recursively mapping Information Items to their identified components, starting with the wsdl:description element information item. This includes the application of the mechanisms described in 4. Modularizing WSDL 2.0 descriptions [p.77] .
This document does not specify a means of producing an XML Infoset representation from a component model instance. In particular, there are in general many valid ways to modularize a given component model instance into one or more XML Infosets.

The Description Component
At the abstract level, the Description [p.13] component is just a container for two categories of components: WSDL 2.0 components and type system components. WSDL 2.0 components are interfaces, bindings and services. Type system components are element declarations and type definitions.
Type system components describe the constraints on a message's content. By default, these constraints are expressed in terms of the [XML Information Set [p.89] ], i.e. they define the [local name], [namespace name], [children] and [attributes] properties of an element information item. Type systems based upon other data models are generally accommodated by extensions to WSDL 2.0; see 6. Language Extensibility [p.82] . In the case where they define information equivalent to that of a XML Schema global element declaration, they can be treated as if they were such a declaration.
This specification does not define the behavior of a WSDL 2.0 document that uses multiple schema languages for describing type system components simultaneously.
An Element Declaration component defines the name and content model of an element information item such as that defined by an XML Schema global element declaration. It has a {name} property that is the QName of the element information item.
A Type Definition component defines the content model of an element information item such as that defined by an XML Schema global type definition. It has a {name} property that is the QName of the type. In addition to WSDL 2.0 components and type system components, additional extension components MAY be added via extensibility 6. Language Extensibility [p.82] . Further, additional properties to WSDL 2.0 and type system components MAY also be added via extensibility.

XML Representation of Description Component
<description targetNamespace="xs:anyURI" > <documentation />* [ <import /> | <include /> ]* <types />? [ <interface /> | <binding /> | <service /> ]* </description> WSDL 2.0 definitions are represented in XML by one or more WSDL 2.0 Information Sets (Infosets), that is one or more description element information items. A WSDL 2.0 Infoset contains representations for a collection of WSDL 2.0 components which share a common target namespace. A WSDL 2.0 Infoset which contains one or more import element information items 4.2 Importing Descriptions [p.79] corresponds to a collection with components drawn from multiple target namespaces.
The components directly defined or included within a Description [p.13] component are said to belong to the same target namespace. The target namespace therefore groups a set of related component definitions and represents an unambiguous name for the intended semantics of the collection of components. The value of the targetNamespace attribute information item SHOULD be a dereferenceable IRI (see [IETF RFC 3987 [p.89] ]). It SHOULD resolve to a human or machine processable document that directly or indirectly defines the intended semantics of those components. It MAY resolve to a WSDL 2.0 document which provides service description information for that namespace.
If a service description is split into multiple documents (which may be combined as needed via 4. Zero or more namespace qualified attribute information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".
Zero or more element information items amongst its [children], in order as follows: 1. Zero or more documentation element information items (see 5. Documentation [p.81] ).
2. Zero or more element information items from among the following, in any order: Zero or more include element information items (see 4.1 Including Descriptions [p.77] ) The type of the targetNamespace attribute information item is xs:anyURI. Its value MUST be an absolute IRI (see [IETF RFC 3987 [p.89] ]).

Mapping Description's XML Representation to Component Properties
The mapping from the XML Representation of the description element information item (see 2.1.2 XML Representation of Description Component [p.14] ) to the properties of the Description [p.13] component is described in ] . Zero or more namespace-qualified element information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".

name attribute information item with interface [owner element]
The name attribute information item together with the targetNamespace attribute information item of the [parent] description element information item forms the QName of the interface.
The name attribute information item has the following Infoset properties: The type of the name attribute information item is xs:NCName.

extends attribute information item
The extends attribute information item lists the interfaces that this interface derives from.
The extends attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the extends attribute information item is a list of xs:QName.

Mapping Interface's XML Representation to Component Properties
The mapping from the XML Representation of the interface element information item (see 2.2.2 XML Representation of Interface Component [p.18] ) to the properties of the Interface [p.17] component is as described in ] .

The Interface Fault Component
A fault is an event that occurs during the execution of a message exchange that disrupts the normal flow of messages.
A fault is typically raised when a party is unable to communicate an error condition inside the normal message flow, or a party wishes to terminate a message exchange. A fault message may be used to communicate out of band information such as the reason for the error, the origin of the fault, as well as other informal diagnostics such as a program stack trace. Zero or more namespace qualified attribute information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".
Zero or more element information item amongst its [children], in order, as follows: 1. Zero or more documentation element information items (see 5. Documentation [p.81] ).
2. Zero or more element information items from among the following, in any order: Zero or more feature element information items 2.7. 2  Zero or more namespace-qualified element information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".

name attribute information item with fault [owner element]
The name attribute information item identifies a given fault element information item inside a given interface element information item.
The name attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the name attribute information item is xs:NCName.

element attribute information item with fault [owner element]
The element attribute information item refers, by QName, to an Element Declaration [p.13] component.
The element attribute information item has the following Infoset properties: A [namespace name] which has no value.
The type of the element attribute information item is xs:QName.

Mapping Interface Fault's XML Representation to Component Properties
The mapping from the XML Representation of the fault element information item (see 2.3. 2

The Interface Operation Component
An Interface Operation [p.25] component describes an operation that a given interface supports. An operation is an interaction with the service consisting of a set of (ordinary and fault) messages exchanged between the service and the other parties involved in the interaction. The sequencing and cardinality of the messages involved in a particular interaction is governed by the message exchange pattern used by the operation (see {message exchange pattern [p.25] } property).
A message exchange pattern defines placeholders for messages, the participants in the pattern (i.e., the sources and sinks of the messages), and the cardinality and sequencing of messages exchanged by the participants. Note that the property MAY not have any value. If this property has a value (a set of IRIs), then for each individual IRI that is an element of that set, the rules implied by that IRI (such as rules that govern the schemas) MUST be followed or it is an error. So, if the set of IRIs has more than one item in it, then the rules implied by ALL the IRIs must be adhered to by the content definitions. Zero or more namespace qualified attribute information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".
One or more element information item amongst its [children], in order, as follows: Zero or more namespace-qualified element information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".

name attribute information item with operation [owner element]
The name attribute information item identifies a given operation element information item inside a given interface element information item.
The name attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the name attribute information item is xs:NCName.

pattern attribute information item with operation [owner element]
The pattern attribute information item identifies the message exchange pattern a given operation uses.
The pattern attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the pattern attribute information item is xs:anyURI. Its value MUST be an absolute IRI (see [IETF RFC 3987 [p.89] ]).

style attribute information item with operation [owner element]
The style attribute information item indicates the rules that were used to construct the {element declara-

Mapping Interface Operation's XML Representation to Component Properties
The mapping from the XML Representation of the operation element information item (see 2.4. 2  Zero or more namespace qualified attribute information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".
Zero or more element information item amongst its [children], in order, as follows: 1. Zero or more documentation element information items (see 5. Documentation [p.81] ).
2. Zero or more element information items from among the following, in any order: Zero or more feature element information items 2.7. 2  Zero or more namespace-qualified element information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".

messageLabel attribute information item with input or output [owner element]
The messageLabel attribute information item identifies the role of this message in the message exchange pattern of the given operation element information item.
The messageLabel attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the messageLabel attribute information item is xs:NCName.

element attribute information item with input or output [owner element]
The element attribute information item has the following Infoset properties: A [namespace name] which has no value.
The type of the element attribute information item is a union of xs:QName and xs:token where the allowed token values are #any, #none, or #other.

Mapping Interface Message Reference's XML Representation to Component Properties
The mapping from the XML Representation of the message reference element information item (see 2.5. 2   The companion specification [WSDL 2.0 Adjuncts [p.89] ] defines two fault patterns that a given message exchange pattern may use. For the pattern fault-replaces-message, the message that the fault relates to identifies the message in place of which the declared fault message will occur. Thus, the fault message will travel in the same direction as the message it replaces in the pattern. For the pattern message-triggers-fault, the message that the fault relates to identifies the message after which the indicated fault may occur, in the opposite direction of the referred to message. That is, the fault message will travel in the opposite direction of the message it comes after in the pattern. Zero or more namespace qualified attribute information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".
Zero or more element information item amongst its [children], in order, as follows: 1. Zero or more documentation element information items (see 5. Documentation [p.81] ).
2. Zero or more element information items from among the following, in any order: Zero or more feature element information items 2.7. 2

messageLabel attribute information item with infault , or outfault [owner element]
The messageLabel attribute information item identifies the message in the message exchange pattern of the given operation element information item to which this fault is related to.
The messageLabel attribute information item has the following Infoset properties: The type of the messageLabel attribute information item is xs:NCName.

Mapping Interface Fault Reference's XML Representation to Component Properties
The mapping from the XML Representation of the message reference element information item (see 2.6. 2   If a given feature is asserted at multiple locations, then the value of that feature at a particular component is determined by the conjunction of all the constraints implied by its asserted values. If a feature is not required then it may or may not be engaged, but if a feature is required then it must be engaged. Therefore, the conjunction of a required value and a non-required value is a required value. A composed feature is required if and only if at least one of its asserted values is required. This rule may be summarized as "true trumps".

Example of Feature Composition Model
In the following example, the depositFunds operation on the BankService has to be used with the ISO9001 , the notarization and the secure-channel features; they are all in scope. The fact that the notarization feature is declared both in the operation and in the binding has no effect.

required attribute information item with feature [owner element]
The required attribute information item specifies whether the use of the feature is mandatory or optional.
The required attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the required attribute information item is xs:boolean .

Mapping Feature's XML Representation to Component Properties
The mapping from the XML Representation of the feature element information item (see 2.7. 2

The Property Component
A "property" in the Features and Properties architecture represents a named runtime value which affects the behavior of some aspect of a Web service interaction, much like an environment variable. For example, a reliable messaging SOAP module may specify a property to control the number of retries in the case of network failure. WSDL 2.0 documents may specify the value constraints for these properties by referring to a Schema type, or by specifying a particular value. Properties, and hence property values, can be shared amongst features/bindings/modules, and are named with IRIs precisely to allow this type of sharing.

Property Composition Model
At runtime, the behavior of features, (SOAP) modules and bindings may be affected by the values of in-scope properties. Properties combine into a virtual "execution context" which maps property names (IRIs) to constraints. Each property IRI MAY therefore be associated with AT MOST one property constraint for a given interaction. If a given Property is asserted at multiple locations, then the value of that Property at a particular component is determined by the conjunction of all the constraints of its in-scope Property [p.42] components. A Property constraint asserts that, for a given interaction, the value of a Property is either a specified value or belongs to a specified set of values. A specified value may be regarded as a singleton set, so in both cases a Property constraint corresponds to an assertion that the Property value belongs to some set. The conjunction of all the constraints associated with the in-scope properties is an assertion that the property value belongs to each of the associated sets, or equivalently, that the value belongs to the intersection of all the associated sets. If the intersection of the associated sets is empty, then the property constraints are mutually incompatible, and the composition is invalid. Therefore, the intersection of the associated sets SHOULD NOT be empty.

Note:
The reason that we phrase the requirement for a non-empty intersection as SHOULD rather than MUST, is that in general, it may be computationally difficult to determine by inspection of the type definitions that the intersection of two or more value sets is empty. Therefore, it is not a strict validity requirement that the intersection of the value sets be non-empty. An empty intersection will always result in failure of the service at run-time.
However, it is in general feasible to test specified values for either equality or membership in value sets.
All specified values MUST be equal and belong to each specified value set. The type of the value element information item is xs:anyType .

constraint element information item with property [parent]
<property> <constraint> xs:QName </constraint> </property> The constraint element information item specifies a constraint on the value of the property. It has the following Infoset properties:

A [local name] of constraint
A [namespace name] of "http://www.w3.org/2005/08/wsdl" The type of the constraint attribute information item is xs:QName .

Mapping Property's XML Representation to Component Properties
The mapping from the XML Representation of the property element information item (see 2.8. 2

name attribute information item with binding [owner element]
The name attribute information item together with the targetNamespace attribute information item of the description element information item forms the QName of the binding.
The name attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the name attribute information item is xs:NCName.

interface attribute information item with binding [owner element]
The interface attribute information item refers, by QName, to an Interface [p.17] component.
The interface attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the interface attribute information item is xs:QName.

type attribute information item with binding [owner element]
The type attribute information item identifies the kind of binding details contained in the Binding [p.48] component.
The type attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the type attribute information item is xs:anyURI.

Binding extension elements
Binding extension elements are used to provide information specific to a particular binding. The semantics of such element information items are defined by the specification for those element information items. Such specifications are expected to annotate the Binding [p.48] component with additional properties and specify the mapping from the XML representation to those properties.

Mapping Binding's XML Representation to Component Properties
The mapping from the XML Representation of the binding element information item (see 2.9. 2

ref attribute information item with fault [owner element]
The ref attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the ref attribute information item is xs:QName.

Binding Fault extension elements
Binding Fault extension elements are used to provide information specific to a particular fault in a binding.
The semantics of such element information items are defined by the specification for those element information items. Such specifications are expected to annotate the Binding Fault [p.51] component with additional properties and specify the mapping from the XML representation to those properties.

Mapping Binding Fault's XML Representation to Component Properties
The mapping from the XML Representation of the fault element information item (see 2.10. 2   Zero or more namespace-qualified element information item whose [namespace name] is NOT " http://www.w3.org/2005/08/wsdl ". Such element information items are considered to be binding operation extension elements as described below (see 2.11.2.2 Binding Operation extension elements [p.56] ).

ref attribute information item with operation [owner element]
The ref attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the ref attribute information item is xs:QName.

Binding Operation extension elements
Binding Operation extension elements are used to provide information specific to a particular operation in a binding. The semantics of such element information items are defined by the specification for those element information items. Such specifications are expected to annotate the Binding Operation [p.54] component with additional properties and specify the mapping from the XML representation to those properties.

Mapping Binding Operation's XML Representation to Component Properties
The mapping from the XML Representation of the operation element information item (see 2.11.2 XML Representation of Binding Operation Component [p.54] ) to the properties of the Binding Operation [p.54] component is as described in ] . Zero or more namespace qualified attribute information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".
Zero or more element information item amongst its [children], in order, as follows: 1. Zero or more documentation element information items (see 5. Documentation [p.81] ).
2. Zero or more element information items from among the following, in any order: Zero or more feature element information items 2.7. 2

messageLabel attribute information item with input or output [owner element]
The messageLabel attribute information item has the following Infoset properties: A [local name] of messageLabel .
A [namespace name] which has no value.
The type of the messageLabel attribute information item is xs:NCName.

Binding Message Reference extension elements
Binding Message Reference extension elements are used to provide information specific to a particular message in an operation. The semantics of such element information items are defined by the specification for those element information items. Such specifications are expected to annotate the Binding Message Reference [p.56] component with additional properties and specify the mapping from the XML representation to those properties..

Mapping Binding Message Reference's XML Representation to Component Properties
The mapping from the XML Representation of the binding element information item (see 2.12. 2

ref attribute information item with infault or outfault [owner element]
The ref attribute information item has the following Infoset properties: A [namespace name] which has no value.
The type of the ref attribute information item is xs:QName.

messageLabel attribute information item with infault or outfault [owner element]
The messageLabel attribute information item has the following Infoset properties: A [local name] of messageLabel .
A [namespace name] which has no value.
The type of the messageLabel attribute information item is xs:NCName.

Binding Fault Reference extension elements
Binding Fault Reference extension elements are used to provide information specific to a particular fault in an operation. The semantics of such element information items are defined by the specification for those element information items. Such specifications are expected to annotate the Binding Fault Reference [p.59] component with additional properties and specify the mapping from the XML representation to those properties..

Mapping Binding Fault Reference's XML Representation to Component Properties
The mapping from the XML Representation of the binding element information item (see 2.13. 2   A REQUIRED interface attribute information item as described below in 2.14.
One or more element information item amongst its [children], in order, as follows: 1. Zero or more documentation element information items (see 5. Documentation [p.81] ).
2. One or more element information items from among the following, in any order: One or more endpoint element information items (see 2.15. 2  Zero or more namespace-qualified element information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".

name attribute information item with service [owner element]
The name attribute information item together with the targetNamespace attribute information item of the description element information item forms the QName of the service.
The name attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the name attribute information item is xs:NCName.

interface attribute information item with service [owner element]
The interface attribute information item identifies the interface that the service is an instance of.
The interface attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the interface attribute information item is xs:QName..

Mapping Service's XML Representation to Component Properties
The mapping from the XML Representation of the service element information item (see 2.14. 2   The QName whose local name is the actual value of the name attribute information item and whose namespace name is the actual value of the targetNamespace attribute information item of the [parent] description element information item. Zero or more namespace qualified attribute information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl".
Zero or more element information item amongst its [children], in order, as follows: 1. Zero or more documentation element information items (see 5. Documentation [p.81] ).
2. Zero or more element information items from among the following, in any order: Zero or more feature element information items 2.7. 2

name attribute information item with endpoint [owner element]
The name attribute information item together with the targetNamespace attribute information item of the description element information item forms the QName of the endpoint.
The name attribute information item has the following Infoset properties: A [namespace name] which has no value.
The type of the name attribute information item is xs:NCName.

binding attribute information item with endpoint [owner element]
The binding attribute information item refers, by QName, to a Binding [p.48] component The binding attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the binding attribute information item is xs:QName.

address attribute information item with endpoint [owner element]
The address attribute information item specifies the address of the endpoint.
The address attribute information item has the following Infoset properties:

A [namespace name] which has no value
The type of the address attribute information item is xs:anyURI.

Endpoint extension elements
Endpoint extension elements are used to provide information specific to a particular endpoint in a server.
The semantics of such element information items are defined by the specification for those element information items. Such specifications are expected to annotate the Endpoint [p.65] component with additional properties and specify the mapping from the XML representation to those properties.

Mapping Endpoint's XML Representation to Component Properties
The mapping from the XML Representation of the endpoint element information item (see 2.15. 2

XML Schema 1.0 Simple Types Used in the Component Model
The XML Schema 1.0 simple types [XML Schema: Datatypes [p.89] ] used in this specification are: Values which are references to other components are considered equivalent when they refer to equivalent components (as determined above).
List-based values are considered equivalent if they have the same length and their elements at corresponding positions are equivalent.  Within a symbol space, all qualified names (that is, the {name} property) are unique. Between symbol spaces, the names need not be unique. Thus it is perfectly coherent to have, for example, a binding and an interface that have the same name.

Symbol Spaces
When XML Schema is being used as one of the type systems for a WSDL 2.0 description, then six other symbol spaces also exist, one for each of: global element declarations, global attribute declarations, named model groups, named attribute groups, type definitions and key constraints, as defined by [XML Schema: Structures [p.89] ]. Other type systems may define additional symbol spaces.

QName resolution
In its serialized form WSDL 2.0 makes significant use of references between components. Such references are made using the Qualified Name, or QName, of the component being referred to. QNames are a tuple, consisting of two parts; a namespace name and a local name.

Comparing URIs and IRIs
This specification uses absolute URIs and IRIs to identify several components (for example, features and properties) and components characteristics (for example, operation message exchange patterns and styles). When such absolute URIs and IRIs are being compared to determine equivalence (see 2.17 Equivalence of Components [p.69] ) they MUST be compared character-by-character as indicated in [TAG URI FINDING [p.89] ].
Although a variety of data models can be accommodated (through WSDL 2.0 extensions), this specification only defines a means of expressing constraints based upon the XML Infoset [XML Information Set [p.89] ]. Furthermore, although a number of alternate schema languages can be used to constrain the XML Infoset (as long as they support the semantics of either inlining or importing schema), this specification only defines the use of XML Schema [XML Schema: Structures [p.89] ], [XML Schema: Datatypes [p.89] ]. When extensions are used to enable the use of a non-Infoset data model, or a non-Schema constraint language, the wsdl:required attribute information item MAY be used to require support for that extension.

Note:
Support for the W3C XML Schema [XML Schema: Structures [p.89] ], [XML Schema: Datatypes [p.89] ] is included in the conformance criteria for WSDL 2.0 documents (see 3. Zero or more element information items from among the following, in any order: xs:import element information items xs:schema element information items Other namespace qualified element information items whose namespace is NOT http://www.w3.org/2005/08/wsdl

Using W3C XML Schema Description Language
XML Schema MAY be used as the schema language via import or inlining.
A WSDL 2.0 description MUST NOT refer to XML Schema components in a given namespace unless an xs:import or xs:schema statement for that namespace is present. That is, using the xs:import or xs:schema constructs is a necessary condition for making XML Schema components available to a WSDL 2.0 description.

Importing XML Schema
Importing an XML Schema uses the syntax and semantics of the xs:import mechanism defined by XML Schema [XML Schema: Structures [p.89] ], [XML Schema: Datatypes [p.89] ], with the differences defined in this and the following section. The schema components defined in the imported namespace are available for reference by QName (see 2.19 QName resolution [p.70] ). Note that only components in the imported namespace are available for reference in the WSDL 2.0 document.
A child element information item of the types element information item is defined with the Infoset properties as follows: A [local name] of "import".
One or two attribute information items as follows: A REQUIRED namespace attribute information item as described below.
An OPTIONAL schemaLocation attribute information item as described below.

namespace attribute information item
The namespace attribute information item defines the namespace of the element declarations and type definitions imported from the referenced schema. The referenced schema MUST contain a target-Namespace attribute information item on its xs:schema element information item and the values of these two attribute information items MUST be identical. It is an error to import a schema that does not have a targetNamespace attribute information item on its xs:schema element information item. Such schemas must first be included (using xs:include ) in a schema that contains a targetNamespace attribute information item on its xs:schema element information item, which can then be either imported or inlined in the WSDL 2.0 document.
The namespace attribute information item has the following Infoset properties: A [local name] of namespace A [namespace name] which has no value.
The type of the namespace attribute information item is xs:anyURI.

schemaLocation attribute information item
The schemaLocation attribute information item, if present, provides a hint to the XML Schema processor as to where the schema may be located. Caching and cataloging technologies may provide better information than this hint. The schemaLocation attribute information item has the following Infoset properties: A [local name] of schemaLocation.
A [namespace name] which has no value.
The type of the schemaLocation attribute information item is xs:anyURI.
It is an error if a QName is not resolved (see 2.19 QName resolution [p.70] ). When resolving QNames references for schema definitions, the namespace MUST be imported by the referring WSDL 2.0 document. If the namespace so referenced is contained in an inline schema, it MAY be imported without a schemaLocation attribute, so long as the inline schema has been resolved in the current component model.

Inlining XML Schema
Inlining an XML schema uses the existing top-level xs:schema element information item defined by XML Schema [XML Schema: Structures [p.89] ]. It may be viewed as simply cutting and pasting an existing schema document to a location inside the types element information item. Inside an inlined XML schema, the xs:import and xs:include element information items MAY be used to refer to other XML schemas inlined in the same or other WSDL 2.0 document, provided that an appropriate value, such as a fragment identifier (see [XML Schema: Structures [p.89] ] 4.3.1) is specified for their schemaLocation attribute information items. For xs:import , the schemaLocation attribute is not required so long as the namespace has been resolved in the current component model. The semantics of such element information items are governed solely by the XML Schema specification [XML Schema: Structures [p.89] ].
Note: It is NOT an error to inline two or more schemas from the same targetNamespace . For example, two or more inlined schemas may have the same targetNamespace provided that they do not define the same elements or types. It is the responsibility of the underlying XML Schema processor to sort out a coherent set of schema components.
The xs:schema element information item has the following Infoset properties: Additional OPTIONAL attribute information items as specified for the xs:schema element information item by the XML Schema specification.
Zero or more child element information items as specified for the xs:schema element information item by the XML Schema specification.

targetNamespace attribute information item
The targetNamespace attribute information item defines the namespace of the element declarations and type definitions inlined in its [owner element] xs:schema element information item. WSDL 2.0 modifies the XML Schema definition of the xs:schema element information item to make this attribute information item required. The targetNamespace attribute information item has the following Infoset properties: A [local name] of targetNamespace.
A [namespace name] which has no value.
The type of the targetNamespace attribute information item is xs:anyURI. A named, global xs:element declaration may be referenced from the element attribute information item of an input , output or fault element information item. The QName is constructed from the targetNamespace of the schema and the value of the name attribute information item of the xs:element element information item. An element attribute information item MUST NOT refer to a global xs:simpleType or xs:complexType definition.

References to Element Declarations and Type Definitions
A named, global xs:simpleType or xs:complexType declaration may be referenced from the constraint attribute information item of property element information item. The QName is constructed from the targetNamespace of the schema and the value of the name attribute information item of the xs:simpleType or xs:complexType element information item. A constraint attribute information item MUST NOT refer to a global xs:element definition.

Using Other Schema Languages
Since it is unreasonable to expect that a single schema language can be used to describe all possible A specification of extension syntax for an alternative schema language MUST include the declaration of an element information item, intended to appear as a child of the wsdl:types element information item, which references, names, and locates the schema instance (an "import" element information item

Note:
This specification does not define the behavior of a WSDL 2.0 document that uses multiple schema languages for describing type system components simultaneously.

Modularizing WSDL 2.0 descriptions
This specification provides two mechanisms, described in this section, for modularizing WSDL 2.0 descriptions. These mechanisms help to make WSDL 2.0 descriptions clearer by allowing separation of the various components of a description. Such separation could be performed according to the level of abstraction of a given set of components, or according to the namespace affiliation required of a given set of components or according to some other grouping such as application applicability.
Both mechanisms work at the level of WSDL 2.0 components and NOT at the level of XML Information Sets or XML 1.0 serializations.

Including Descriptions
<description> <include location="xs:anyURI" > <documentation />* </include> </description> The WSDL 2.0 include element information item allows for the separation of different components of a service definition, belonging to the same target namespace, into independent WSDL 2.0 documents.
The WSDL 2.0 include element information item is modeled after the XML Schema include element information item (see [XML Schema: Structures [p.89] ], section 4.2.3 "References to schema components in the same namespace"). Specifically, it can be used to include components from WSDL 2.0 descriptions that share a target namespace with the including description. Components in the transitive closure of the included WSDL 2.0 documents become part of the Description component of the including WSDL 2.0 document. The included components can be referenced by QName. Note that because all WSDL 2.0 descriptions have a target namespace, no-namespace includes (sometimes known as "chameleon includes") never occur in WSDL 2.0.
A mutual include is direct inclusion by one WSDL 2.0 document of another WSDL 2.0 document which includes the first. A circular include achieves the same effect with greater indirection (A s B includes C includes A, for instance). Multiple inclusion of a single WSDL 2.0 document resolves to a single set of components. Mutual, multiple, and circular includes are explicitly permitted, and do not represent multiple redefinitions of the same components. Multiple inclusion of a single WSDL 2.0 document has the same meaning as including it only once.
The include element information item has: A [local name] of include .
One or more attribute information items amongst its [attributes] as follows: A REQUIRED location attribute information item as described below in 4.
Zero or more element information item amongst its [children], as follows: Zero or more documentation element information items (see 5. Documentation [p.81] ).

location attribute information item with include [owner element]
The location attribute information item has the following Infoset properties: A [namespace name] which has no value.
A location attribute information item is of type xs:anyURI . Its actual value is the location of some information about the namespace identified by the targetNamespace attribute information item of the containing description element information item.
It is an error if the IRI indicated by location does not resolve to a WSDL 2.0 document.
The actual value of the targetNamespace attribute information item of the included WSDL 2.0 document MUST match the actual value of the targetNamespace attribute information item of the description element information item which is the [parent] of the include element information item.

Importing Descriptions
<description> <import namespace="xs:anyURI" location="xs:anyURI"? > <documentation />* </import> </description> Every top-level WSDL 2.0 component is associated with a target namespace. On its ws:description element information item, WSDL 2.0 documents carries a targetNamespace attribute information item that associates the document with a target namespace. This section describes the syntax and mechanisms by which references may be made from within a WSDL 2.0 document to components not within the document's target namespace. In addition to this syntax, there is an optional facility for suggesting the IRI of a WSDL 2.0 document containing definition components from that foreign target namespace.
The WSDL 2.0 import element information item is modeled after the XML Schema xs:import element information item (see [XML Schema: Structures [p.89] ], section 4.2.3 "References to schema components across namespaces"). Specifically, it can be used to import components from WSDL descriptions that do not share a target namespace with the importing document. The WSDL 2.0 ws:import element information item identifies namespaces used in foreign references. The existence of the WSDL 2.0 ws:import element information item signals that the WSDL 2.0 document may contain references to foreign components. The ws:import element information item is therefore like a forward declaration for other namespaces.
As with XML schema, each WSDL 2.0 document making references to components in a given (foreign) namespace MUST have an import element information item for that namespace (but not necessarily providing a location attribute information item identifying the WSDL 2.0 document in which the referenced component is declared). In other respects, the visibility of components is pervasive; if two WSDL 2.0 documents import the same namespace then they will have access to the same components from the imported namespace (i.e. regardless of which, if any, location attribute information item values are provided on the respective import element information items.) Using the import element information item is a necessary condition for making components from another namespace available to a WSDL 2.0 document. That is, a WSDL 2.0 document can only refer to components in a namespace other than its own target namespace if the WSDL 2.0 document contains an import element information item for that foreign namespace. This specification does not preclude repeating the import element information item for the same value of the namespace attribute information item as long as they provide different values for the location attribute information item. Repeating the import element information item for the same namespace value MAY be used as a way to provide alternate locations to find information about a given namespace.
Furthermore, this specification DOES NOT require the location attribute information item to be dereferenceable. If it is not dereferenceable then no information about the imported namespace is provided by that import element information item. It is possible that such lack of information can cause QNames in other parts of a WSDL 2.0 Description component to become broken references (see 2.19 QName resolu-tion [p.70] ). Such broken references are not errors of the import element information item but rather QName resolution errors which must be detected as described in 2.19 QName resolution [p.70] .
One or more attribute information items amongst its [attributes] as follows: A REQUIRED namespace attribute information item as described below in 4.2.1 namespace attribute information item [p.80] .
An OPTIONAL location attribute information item as described below in 4.
Zero or more element information items amongst its [children], as follows: Zero or more documentation element information items (see 5. Documentation [p.81] ).

namespace attribute information item
The namespace attribute information item has the following Infoset properties: A [local name] of namespace .
A [namespace name] which has no value.
The namespace attribute information item is of type xs:anyURI . Its actual value indicates that the containing WSDL 2.0 document MAY contain qualified references to WSDL 2.0 definitions in that namespace (via one or more prefixes declared with namespace declarations in the normal way). This value MUST NOT match the actual value of targetNamespace attribute information item in the enclosing WSDL 2.0 document. If the location attribute in the import element information item references a WSDL 2.0 document, then the actual value of the namespace attribute information item MUST be identical to the actual value of the targetNamespace attribute information item in the referenced WSDL 2.0 document.

location attribute information item with import [owner element]
The location attribute information item has the following Infoset properties: A [local name] of location .
A [namespace name] which has no value.
The location attribute information item is of type xs:anyURI . Its actual value, if present, gives a hint as to where a serialization of a WSDL 2.0 document with definitions for the imported namespace can be found.
The location attribute information item is optional. This allows WSDL 2.0 components to be constructed from information other than serialized XML 1.0 or a WSDL 2.0 document. It also allows the development of WSDL 2.0 processors that have a prior (i.e., built-in) knowledge of certain namespaces.

<documentation>
[extension elements]* </documentation> WSDL 2.0 uses the optional documentation element information item as a container for human readable and/or machine processable documentation. The content of the element information item is arbitrary character information items and element information items ("mixed" content in XML Schema [XML Schema: Structures [p.89] ]). The documentation element information item is allowed inside any WSDL 2.0 element information item.
Like other element information items in the "http://www.w3.org/2005/08/wsdl" namespace, the documentation element information item allows qualified attribute information items whose [namespace name] is not "http://www.w3.org/2005/08/wsdl". The xml:lang attribute (see [XML 1.0 [p.89] ]) MAY be used to indicate the language used in the contents of the documentation element information item.

Language Extensibility
In addition to extensibility implied by the Feature [p.38] and Property [p.42] components described above, the schema for WSDL 2.0 has a two-part extensibility model based on namespace-qualified elements and attributes. An extension is identified by the QName consisting of its namespace IRI and its element name. The meaning of an extension SHOULD be defined (directly or indirectly) in a document that is available at its namespace IRI.

Element based Extensibility
WSDL 2.0 allows extensions to be defined in terms of element information items. Where indicated herein, WSDL 2.0 allows namespace-qualified element information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl" to appear among the [children] of specific element information items whose [namespace name] is "http://www.w3.org/2005/08/wsdl". Such element information items MAY be used to annotate WSDL 2.0 constructs such as interface, operation, etc.
It is expected that extensions will want to add to the existing properties of components in the component model. The specification for an extension element information item should include definitions of any such properties and the mapping from the XML representation of the extension to the properties in the component model.
The WSDL 2.0 schema also defines a base type for use by extensibility elements.  shows the type definition. The use of this type as a base type is optional. The element declarations which serve as the heads of the defined substitution groups are all of type "xs:anyType".
Extensibility elements are commonly used to specify some technology-specific binding. They allow innovation in the area of network and message protocols without having to revise the base WSDL 2.0 specification. WSDL 2.0 recommends that specifications defining such protocols also define any necessary WSDL 2.0 extensions used to describe those protocols or formats.

Mandatory extensions
Extension elements can be marked as mandatory by annotating them with a wsdl:required attribute information item (see 6.1.2 required attribute information item [p.84] ) with a value of "true". A mandatory extension is an extension that MAY change the meaning of the element to which it is attached, such that the meaning of that element is no longer governed by this specification. Instead, the meaning of an element containing a mandatory extension is governed by the meaning of that extension. Thus, the definition of the element's meaning is delegated to the specification that defines the extension.
An extension that is NOT marked as mandatory MUST NOT invalidate the meaning of any part of the WSDL 2.0 document. Thus, a NON-mandatory extension merely provides additional description of capabilities of the service. This specification does not provide a mechanism to mark extension attributes as being required. Therefore, all extension attributes are NON-mandatory.

Note:
A mandatory extension is considered mandatory because it has the ability to change the meaning of the element to which it is attached. Thus, the meaning of the element may not be fully understood without understanding the attached extension. A NON-mandatory extension, on the other hand, can be safely ignored without danger of misunderstanding the rest of the WSDL 2.0 document.
If a WSDL 2.0 document declares an extension, Feature or Property as optional (i.e., NON-mandatory), then the Web service MUST NOT assume that the client supports that extension, Feature or Property, unless the Web service knows (through some other means) that the client has in fact elected to engage and support that extension, Feature or Property.

Note:
A key purpose of an extension is to formally indicate (i.e., in a machine-processable way) that a particular feature or convention is supported or required. This enables toolkits that understand the extension to engage it automatically, while toolkits that do not yet understand a required extension may be able to flag it to an operator for manual support.
If a Web service requires the client to follow a particular convention that is likely to be automatable in WSDL 2.0 toolkits, then that convention SHOULD be indicated in the WSDL 2.0 document as a wsdl:required extension, rather than just being conveyed out of band, even if that convention is not currently implemented in WSDL 2.0 toolkits. This practice will help prevent interoperability problems that could arise if one toolkit requires a particular convention that is not indicated in the WSDL 2.0 document, while another toolkit does not realize that that convention is required. It will also help facilitate future automatic processing by WSDL 2.0 toolkits.
On the other hand, a client MAY engage an extension, Feature or Property that is declared as optional in the WSDL 2.0 document. Therefore, the Web service MUST support every extension, Feature or Property that is declared as optional in the WSDL 2.0 document, in addition to supporting every extension, Feature or Property that is declared as mandatory.

Note:
If finer-grain, direction-sensitive control of extensions, Features or Properties is desired, then such extensions, Features or Properties may be designed in a direction-sensitive manner (from the client or from the Web service) so that either direction may be separately marked required or optional. For example, instead of defining a single extension that governs both directions, two extensions could be defined --one for each direction. WSDL 2.0 provides a global attribute information item with the following Infoset properties:

required attribute information item
A [local name] of required .
The type of the required attribute information item is xs:boolean. Its default value is "false" (hence extensions are NOT required by default). WSDL 2.0 allows qualified attribute information items whose [namespace name] is NOT "http://www.w3.org/2005/08/wsdl" to appear on any element information item whose namespace name IS "http://www.w3.org/2005/08/wsdl". Such attribute information items can be used to annotate WSDL 2.0 constructs such as interfaces, bindings, etc. WSDL 2.0 does not provide a mechanism for marking extension attribute information items as mandatory.

Extensibility Semantics
As indicated above, it is expected that the presence of extensibility elements and attributes will result in additional properties appearing in the component model.
The presence of an optional extensibility element or attribute MAY therefore augment the semantics of a WSDL 2.0 document in ways that do not invalidate the existing semantics. However, the presence of a mandatory extensibility element MAY alter the semantics of a WSDL 2.0 document in ways that invalidate the existing semantics.
Extensibility elements SHOULD NOT alter the existing semantics in ways that are likely to confuse users.

Note:
However, once the client and service both know that an optional feature has been engaged (because the service has received a message explicitly engaging that feature, for example), then the semantics of that feature supercede what the WSDL 2.0 document indicated. For example, the WSDL 2.0 document may have specified an XML message schema to be used, but also indicated an optional security feature that encrypts the messages. If the security feature is engaged, then the encrypted messages will no longer conform to the specified message schema (until they are decrypted).

Note:
Authors of extensibility elements should make sure to include in the specification for such elements a clear statement of the requirements for document conformance (see 1.2 Document Conformance [p.7] ).

Locating WSDL 2.0 Documents
As an XML vocabulary, WSDL documents, WSDL fragments or references to WSDL components -via QNames-MAY appear within other XML documents. This specification defines a global attribute, wsdl-Location , to help with QName resolution (see 2.19 QName resolution [p.70] ). This attribute allows an element that contains such references to be annotated to indicate where the WSDL for a namespace (or set of namespaces) can be found. In particular, this attribute is expected to be useful when using service references in message exchanges.
The wsdlLocation global attribute is defined in the namespace "http://www.w3.org/2005/08/wsdl-instance" (hereafter referred to as "wsdli:wsdlLocation", for brevity). This attribute MAY appear on any XML element which allows attributes from other namespaces to occur. It MUST NOT appear on a wsdl:description element or any of its children/descendants.

wsdli:wsdlLocation attribute information item
A [local name] of wsdlLocation .
The type of the wsdlLocation attribute information item is a list xs:anyURI (of even length). Its actual value MUST be a list of pairs of IRIs; where the first IRI of a pair, which MUST be an absolute IRI as defined in [IETF RFC 3987 [p.89] ], indicates a WSDL 2.0 (or 1.1) namespace name, and, the second a hint as to the location of a WSDL 2.0 document defining WSDL 2.0 components (or WSDL 1.1 elements [WSDL 1.1 [p.90] ]) for that namespace name. The second IRI of a pair MAY be absolute or relative.

XML Information Set Conformance
This specification conforms to the [XML Information Set [p.89] ]. The following information items MUST be present in the input Infosets to enable correct processing of WSDL 2.0 documents:
Applications which use this media type: No known applications currently use this media type.
Additional information: File extension: wsdl Fragment identifiers: Either a syntax identical to that of "application/xml" as described in [RFC 3023 [p.89] ], section 5 or the syntax defined in A.2 Fragment Identifiers [p.93] .
Macintosh File Type code: WSDL Person and email address to contact for further information: World Wide Web Consortium <web-human@w3.org> Intended usage:

COMMON
Author/Change controller: The WSDL 2.0 specification set is a work product of the World Wide Web Consortium's Web Service Description Working Group. The W3C has change control over these specifications.

A.2 Fragment Identifiers
This section defines a fragment identifier syntax for identifying components of a WSDL 2.0 document. This fragment identifier syntax is compliant with the [XPointer Framework [p.91] ].
A WSDL 2.0 fragment identifier consists of zero or more xmlns pointer parts followed by a pointer part as defined below. The pointer parts have a scheme name that corresponds to one of the standard WSDL 2.0 component types, and scheme data that is a path composed of names that identify the components. The scheme names all begin with the prefix "wsdl." to avoid name conflicts with other schemes. The names in the path are of type either QName, NCName, IRI, URI, or Pointer Part depending on the context.