W3C

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language

W3C Candidate Recommendation 27 March 2006
Non-normative version with Z Notation

Normative version at:
http://www.w3.org/TR/2006/CR-wsdl20-20060327
Latest version:
http://www.w3.org/TR/wsdl20
Previous versions:
http://www.w3.org/TR/2006/CR-wsdl20-20060106
Editors:
Roberto Chinnici, Sun Microsystems
Jean-Jacques Moreau, Canon
Arthur Ryman, IBM
Sanjiva Weerawarana, WSO2

This document is also available in these non-normative formats: XHTML with Z Notation, PDF, PDF with Z Notation, PostScript, XML, and plain text.

Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document describes the Web Services Description Language Version 2.0 (WSDL 2.0), an XML language for describing Web services. This specification defines the core language which can be used to describe Web services based on an abstract model of what the service offers. It also defines the conformance criteria for documents in this language.

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/.

This is an updated version of the W3C Candidate Recommendation of Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language for review by W3C Members and other interested parties. It has been produced by the Web Services Description Working Group, which is part of the W3C Web Services Activity. The publication of this document signifies a call for implementations of this specification. The Candidate Recommendation period specified in the previous draft (15 March 2006) has passed. The Working Group does not anticipate garnering enough implementation experience to fulfill its Candidate Recommendation exit criteria until at least 1 July 2006.

This version addresses the modest number of comments received to date on the Candidate Recommendation of Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, and primarily differs from the previous version in the inclusion of marked test assertions to help implementers. The detailed disposition of the comments received can be found in the Candidate Recommendation issues list. 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.

The Working Group plans to submit this specification for consideration as a W3C Proposed Recommendation if the following exit criteria have been met:

The sections 2.7 Feature and 2.8 Property in this specification, defining the feature and property components, are considered at risk. The Working Group may recommend to remove the components from the specification, depending on their use and the implementations.

Implementers are invited to send feedback on this document to the public public-ws-desc-comments@w3.org mailing list (public archive).

Issues about this document are recorded in the Candidate Recommendation 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 Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. 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.

Short Table of Contents

1. Introduction
2. Component Model
3. Types
4. Modularizing WSDL 2.0 descriptions
5. Documentation
6. Language Extensibility
7. Locating WSDL 2.0 Documents
8. Conformance
9. XML Syntax Summary (Non-Normative)
10. References
A. The application/wsdl+xml Media Type
B. Acknowledgements (Non-Normative)
C. IRI-References for WSDL 2.0 Components (Non-Normative)
D. Component Summary (Non-Normative)
E. Part 1 Change Log (Non-Normative)
F. Assertion Summary (Non-Normative)

Table of Contents

1. Introduction
    1.1 Web Service
    1.2 Document Conformance
    1.3 The Meaning of a Service Description
    1.4 Notational Conventions
        1.4.1 RFC 2119 Keywords
        1.4.2 RFC 3986 Namespaces
        1.4.3 XML Schema anyURI
        1.4.4 Prefixes and Namespaces Used in This Specification
        1.4.5 Terms Used in This Specification
        1.4.6 XML Information Set Properties
        1.4.7 WSDL 2.0 Component Model Properties
        1.4.8 Z Notation
        1.4.9 BNF Pseudo-Schemas
        1.4.10 Assertions
2. Component Model
    2.1 Description
        2.1.1 The Description Component
        2.1.2 XML Representation of Description Component
            2.1.2.1 targetNamespace attribute information item
        2.1.3 Mapping Description's XML Representation to Component Properties
    2.2 Interface
        2.2.1 The Interface Component
        2.2.2 XML Representation of Interface Component
            2.2.2.1 name attribute information item with interface [owner element]
            2.2.2.2 extends attribute information item
            2.2.2.3 styleDefault attribute information item
        2.2.3 Mapping Interface's XML Representation to Component Properties
    2.3 Interface Fault
        2.3.1 The Interface Fault Component
        2.3.2 XML Representation of Interface Fault Component
            2.3.2.1 name attribute information item with fault [owner element]
            2.3.2.2 element attribute information item with fault [owner element]
        2.3.3 Mapping Interface Fault's XML Representation to Component Properties
    2.4 Interface Operation
        2.4.1 The Interface Operation Component
            2.4.1.1 Message Exchange Pattern
            2.4.1.2 Operation Style
        2.4.2 XML Representation of Interface Operation Component
            2.4.2.1 name attribute information item with operation [owner element]
            2.4.2.2 pattern attribute information item with operation [owner element]
            2.4.2.3 style attribute information item with operation [owner element]
        2.4.3 Mapping Interface Operation's XML Representation to Component Properties
    2.5 Interface Message Reference
        2.5.1 The Interface Message Reference Component
        2.5.2 XML Representation of Interface Message Reference Component
            2.5.2.1 messageLabel attribute information item with input or output [owner element]
            2.5.2.2 element attribute information item with input or output [owner element]
        2.5.3 Mapping Interface Message Reference's XML Representation to Component Properties
    2.6 Interface Fault Reference
        2.6.1 The Interface Fault Reference Component
        2.6.2 XML Representation of Interface Fault Reference
            2.6.2.1 ref attribute information item with infault, or outfault [owner element]
            2.6.2.2 messageLabel attribute information item with infault, or outfault [owner element]
        2.6.3 Mapping Interface Fault Reference's XML Representation to Component Properties
    2.7 Feature
        2.7.1 The Feature Component
            2.7.1.1 Feature Composition Model
                2.7.1.1.1 Example of Feature Composition Model
        2.7.2 XML Representation of Feature Component
            2.7.2.1 ref attribute information item with feature [owner element]
            2.7.2.2 required attribute information item with feature [owner element]
        2.7.3 Mapping Feature's XML Representation to Component Properties
    2.8 Property
        2.8.1 The Property Component
            2.8.1.1 Property Composition Model
        2.8.2 XML Representation of Property Component
            2.8.2.1 ref attribute information item with property [owner element]
            2.8.2.2 value element information item with property [parent]
            2.8.2.3 constraint element information item with property [parent]
        2.8.3 Mapping Property's XML Representation to Component Properties
    2.9 Binding
        2.9.1 The Binding Component
        2.9.2 XML Representation of Binding Component
            2.9.2.1 name attribute information item with binding [owner element]
            2.9.2.2 interface attribute information item with binding [owner element]
            2.9.2.3 type attribute information item with binding [owner element]
            2.9.2.4 Binding extension elements
        2.9.3 Mapping Binding's XML Representation to Component Properties
    2.10 Binding Fault
        2.10.1 The Binding Fault Component
        2.10.2 XML Representation of Binding Fault Component
            2.10.2.1 ref attribute information item with fault [owner element]
            2.10.2.2 Binding Fault extension elements
        2.10.3 Mapping Binding Fault's XML Representation to Component Properties
    2.11 Binding Operation
        2.11.1 The Binding Operation Component
        2.11.2 XML Representation of Binding Operation Component
            2.11.2.1 ref attribute information item with operation [owner element]
            2.11.2.2 Binding Operation extension elements
        2.11.3 Mapping Binding Operation's XML Representation to Component Properties
    2.12 Binding Message Reference
        2.12.1 The Binding Message Reference Component
        2.12.2 XML Representation of Binding Message Reference Component
            2.12.2.1 messageLabel attribute information item with input or output [owner element]
            2.12.2.2 Binding Message Reference extension elements
        2.12.3 Mapping Binding Message Reference's XML Representation to Component Properties
    2.13 Binding Fault Reference
        2.13.1 The Binding Fault Reference Component
        2.13.2 XML Representation of Binding Fault Reference Component
            2.13.2.1 ref attribute information item with infault or outfault [owner element]
            2.13.2.2 messageLabel attribute information item with infault or outfault [owner element]
            2.13.2.3 Binding Fault Reference extension elements
        2.13.3 Mapping Binding Fault Reference's XML Representation to Component Properties
    2.14 Service
        2.14.1 The Service Component
        2.14.2 XML Representation of Service Component
            2.14.2.1 name attribute information item with service [owner element]
            2.14.2.2 interface attribute information item with service [owner element]
        2.14.3 Mapping Service's XML Representation to Component Properties
    2.15 Endpoint
        2.15.1 The Endpoint Component
        2.15.2 XML Representation of Endpoint Component
            2.15.2.1 name attribute information item with endpoint [owner element]
            2.15.2.2 binding attribute information item with endpoint [owner element]
            2.15.2.3 address attribute information item with endpoint [owner element]
            2.15.2.4 Endpoint extension elements
        2.15.3 Mapping Endpoint's XML Representation to Component Properties
    2.16 XML Schema 1.0 Simple Types Used in the Component Model
    2.17 Equivalence of Components
    2.18 Symbol Spaces
    2.19 QName resolution
    2.20 Comparing URIs and IRIs
3. Types
    3.1 Using W3C XML Schema Description Language
        3.1.1 Importing XML Schema
            3.1.1.1 namespace attribute information item
            3.1.1.2 schemaLocation attribute information item
        3.1.2 Inlining XML Schema
            3.1.2.1 targetNamespace attribute information item
        3.1.3 References to Element Declarations and Type Definitions
    3.2 Using Other Schema Languages
    3.3 Describing Messages that Refer to Services and Endpoints
        3.3.1 wsdlx:interface attribute information item
        3.3.2 wsdlx:binding attribute information item
        3.3.3 wsdlx:interface and wsdlx:binding Consistency
        3.3.4 Use of wsdlx:interface and wsdlx:binding with xs:anyURI
4. Modularizing WSDL 2.0 descriptions
    4.1 Including Descriptions
        4.1.1 location attribute information item with include [owner element]
    4.2 Importing Descriptions
        4.2.1 namespace attribute information item
        4.2.2 location attribute information item with import [owner element]
5. Documentation
6. Language Extensibility
    6.1 Element based Extensibility
        6.1.1 Mandatory extensions
        6.1.2 required attribute information item
    6.2 Attribute-based Extensibility
    6.3 Extensibility Semantics
7. Locating WSDL 2.0 Documents
    7.1 wsdli:wsdlLocation attribute information item
8. Conformance
    8.1 XML Information Set Conformance
9. XML Syntax Summary (Non-Normative)
10. References
    10.1 Normative References
    10.2 Informative References

Appendices

A. The application/wsdl+xml Media Type
    A.1 Registration
    A.2 Fragment Identifiers
        A.2.1 The Description Component
        A.2.2 The Element Declaration Component
        A.2.3 The Type Definition Component
        A.2.4 The Interface Component
        A.2.5 The Interface Fault Component
        A.2.6 The Interface Operation Component
        A.2.7 The Interface Message Reference Component
        A.2.8 The Interface Fault Reference Component
        A.2.9 The Binding Component
        A.2.10 The Binding Fault Component
        A.2.11 The Binding Operation Component
        A.2.12 The Binding Message Reference Component
        A.2.13 The Binding Fault Reference Component
        A.2.14 The Service Component
        A.2.15 The Endpoint Component
        A.2.16 The Feature Component
        A.2.17 The Property Component
        A.2.18 Extension Components
    A.3 Security considerations
B. Acknowledgements (Non-Normative)
C. IRI-References for WSDL 2.0 Components (Non-Normative)
    C.1 WSDL 2.0 IRIs
    C.2 Example
D. Component Summary (Non-Normative)
E. Part 1 Change Log (Non-Normative)
    E.1 WSDL 2.0 Specification Changes
F. Assertion Summary (Non-Normative)

1. 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] describes extensions for Message Exchange Patterns, SOAP modules, and a language for describing such concrete details for SOAP 1.2 [SOAP 1.2 Part 1: Messaging Framework] and HTTP [IETF RFC 2616].

1.1 Web Service

WSDL 2.0 describes a Web service in two fundamental stages: one abstract and one concrete. Within each stage, the description uses a number of constructs to promote reusability of the description and to separate independent design concerns.

At an abstract level, WSDL 2.0 describes a Web service in terms of the messages it sends and receives; messages are described independent of a specific wire format using a type system, typically XML Schema.

An 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.

1.2 Document Conformance

An element information item (as defined in [XML Information Set]) whose namespace name is "http://www.w3.org/2006/01/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/2006/01/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] 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 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.

1.3 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, if the WSDL 2.0 document specifies a particular optional extension, the functionality implied by that extension is only optional to the client. It must 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.

1.4 Notational Conventions

All parts of this specification are normative, with the EXCEPTION of notes, pseudo-schemas, examples, and sections explicitly marked as “Non-Normative”.

1.4.1 RFC 2119 Keywords

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

1.4.2 RFC 3986 Namespaces

Namespace names of the general form:

  • "http://example.org/..." and

  • "http://example.com/..."

represent application or context-dependent URIs [IETF RFC 3986].

1.4.3 XML Schema anyURI

This specification uses the XML Schema type xs:anyURI (see [XML Schema: Datatypes]). It is defined so that xs:anyURI values are essentially IRIs (see [IETF RFC 3987]). The conversion from xs:anyURI values to an actual URI is via an escaping procedure defined by (see [XML Linking Language (XLink) 1.0]), which is identical in most respects to IRI Section 3.1.

For interoperability, WSDL authors are advised to avoid the US-ASCII characters: "<", ">", '"', space, "{", "}", "|", "\", "^", and "`", which are allowed by the xs:anyURI type, but disallowed in IRIs.

1.4.4 Prefixes and Namespaces Used in This Specification

This specification uses predefined namespace prefixes throughout; they are given in the following list. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [XML Namespaces]).

wsdl

"http://www.w3.org/2006/01/wsdl"

Defined by this specification.

wsdli

"http://www.w3.org/2006/01/wsdl-instance"

Defined by this specification 7.1 wsdli:wsdlLocation attribute information item.

wsdlx

"http://www.w3.org/2006/01/wsdl-extensions"

Defined by this specification 3.3 Describing Messages that Refer to Services and Endpoints.

wrpc

"http://www.w3.org/2006/01/wsdl/rpc"

Defined by WSDL 2.0: Adjuncts [WSDL 2.0 Adjuncts].

wsoap

"http://www.w3.org/2006/01/wsdl/soap"

Defined by WSDL 2.0: Adjuncts [WSDL 2.0 Adjuncts].

whttp

"http://www.w3.org/2006/01/wsdl/http"

Defined by WSDL 2.0: Adjuncts [WSDL 2.0 Adjuncts].

xs

"http://www.w3.org/2001/XMLSchema"

Defined in the W3C XML Schema specification [XML Schema: Structures], [XML Schema: Datatypes].

xsi

"http://www.w3.org/2001/XMLSchema-instance"

Defined in the W3C XML Schema specification [XML Schema: Structures], [XML Schema: Datatypes].

1.4.5 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], 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, an 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.

1.4.6 XML Information Set Properties

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

1.4.7 WSDL 2.0 Component Model Properties

This specification defines and refers to properties in the WSDL 2.0 Component Model 2. Component Model. Such properties are denoted by curly brackets, e.g. {name}, {interfaces}.

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.

1.4.8 Z Notation

Z Notation [Z Notation Reference Manual] 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].

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 preceding 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.6 XML Information Set Properties. 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.7 WSDL 2.0 Component Model Properties. 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.

1.4.9 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. Pseudo schemas do not include extensibility points for brevity.

<!-- sample pseudo-schema -->
<defined_element
      required_attribute_of_type_string="xs:string"
      optional_attribute_of_type_int="xs:int"? >
  <required_element />
  <optional_element />?
  <one_or_more_of_these_elements />+
  [ <choice_1 /> | <choice_2 /> ]*
</defined_element>

1.4.10 Assertions

Assertions about WSDL 2.0 documents and components that are not enforced by the normative XML schema for WSDL 2.0 are marked by a dagger symbol (†) at the end of a sentence. Each assertion has been assigned a unique identifier that consists of a descriptive textual prefix and a unique numeric suffix. The numeric suffixes are assigned sequentially and never reused so there may be gaps in the sequence. The assertion identifiers MAY be used by implementations of this specification for any purpose, e.g. error reporting.

The assertions and their identifiers are summarized in section F. Assertion Summary.

2. 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. A valid WSDL 2.0 component model is a set of WSDL 2.0 components and properties that satisfy all the requirements given in this specification as indicated by keywords whose interpretation is defined by RFC 2119 [IETF RFC 2119].

ComponentModel  [ show all ]  [ hide all ]

A WSDL 2.0 document, and its related documents, defines a set of components that together form an instance of a Component Model. This specification defines the structure and constraints on the components in a valid component model instance.

Let ComponentModel be the set of valid component model instances:

ComponentModel
DescriptionCM
ElementDeclarationCM
TypeDefinitionCM
FeatureCM
PropertyCM
InterfaceCM
InterfaceFaultCM
InterfaceOperationCM
InterfaceMessageReferenceCM
InterfaceFaultReferenceCM
BindingCM
BindingFaultCM
BindingOperationCM
BindingMessageReferenceCM
BindingFaultReferenceCM
ServiceCM
EndpointCM
See DescriptionCM, ElementDeclarationCM, TypeDefinitionCM, FeatureCM, PropertyCM, InterfaceCM, InterfaceFaultCM, InterfaceOperationCM, InterfaceMessageReferenceCM, InterfaceFaultReferenceCM, BindingCM, BindingFaultCM, BindingOperationCM, BindingMessageReferenceCM, BindingFaultReferenceCM, ServiceCM, EndpointCM.

The definition of ComponentModel is built up from definitions for each of the component types. A component model instance is valid if and only if the constraints on each of the component types are satisfied. The component type definitions are given in the following sections.

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].

Component  [ show all ]  [ hide all ]

Let Component be the union of each of the component types that appear in the WSDL 2.0 component model:

Component ::=
      description〈〈Description〉〉|
      elementDecl〈〈ElementDeclaration〉〉|
      typeDef〈〈TypeDefinition〉〉|
      interface〈〈Interface〉〉|
      interfaceFault〈〈InterfaceFault〉〉|
      interfaceOp〈〈InterfaceOperation〉〉|
      interfaceMessageRef〈〈InterfaceMessageReference〉〉|
      interfaceFaultRef〈〈InterfaceFaultReference〉〉|
      feature〈〈Feature〉〉|
      property〈〈Property〉〉|
      binding〈〈Binding〉〉|
      bindingFault〈〈BindingFault〉〉|
      bindingOp〈〈BindingOperation〉〉|
      bindingMessageRef〈〈BindingMessageReference〉〉|
      bindingFaultRef〈〈BindingFaultReference〉〉|
      service〈〈Service〉〉|
      endpoint〈〈Endpoint〉〉
See Description, ElementDeclaration, TypeDefinition, Interface, InterfaceFault, InterfaceOperation, InterfaceMessageReference, InterfaceFaultReference, Feature, Property, Binding, BindingFault, BindingOperation, BindingMessageReference, BindingFaultReference, Service, Endpoint.

The Component type is an example of a Z Notation free type. The structure of a free type is similar to that of a variant record or discriminated union datatype that are found in some common programming languages. Each of the members of this union is formally defined in the following sections.

ID...
ID  [ show all ]  [ hide all ]

When a component property is said to contain another component or a set of other components, the intended meaning is that the component property contains a reference to another component or a set of references to other components. Every component contains an unique identifier that is used to express references.

Let ID be the set of all component identifier values:

[ID]

The ID type is an example of a Z Notation basic set. The structure of a basic set is immaterial. The only relevant aspect of ID is that it contains enough members to uniquely identify each component, and that these identifiers can be compared for equality. These identifiers are similar to XML element ids or object identifiers that are found in common object-oriented programming languages.

Identifier  [ show all ]  [ hide all ]

Every component has an identifier which uniquely identifies it within a component model instance.

Let Identifier be the set of component identifier properties:

  • Let id be the identifier of the component.

Identifier
id : ID
See ID.

The Identifier set is a an example of Z Notation schema. The structure of a Z schema is similar to that of a record or struct datatype that are found in many common programming languages. The fields of an instance of a Z schema are selected using the usual dot notation, e.g. x.id selects the id field of the instance x.

All component properties that contain an ID, except for Identifier, refer to other components. Every ID value that appears in a component reference corresponds to a unique component in the component model with that identifier.

Id...
Id  [ show all ]  [ hide all ]

Let Id map components to their identifiers:

Id : Component→ID
∀x : Description • Id(description(x)) = x.id
∀x : ElementDeclaration • Id(elementDecl(x)) = x.id
∀x : TypeDefinition • Id(typeDef(x)) = x.id
∀x : Interface • Id(interface(x)) = x.id
∀x : InterfaceFault • Id(interfaceFault(x)) = x.id
∀x : InterfaceOperation • Id(interfaceOp(x)) = x.id
∀x : InterfaceMessageReference • Id(interfaceMessageRef(x)) = x.id
∀x : InterfaceFaultReference • Id(interfaceFaultRef(x)) = x.id
∀x : Feature • Id(feature(x)) = x.id
∀x : Property • Id(property(x)) = x.id
∀x : Binding • Id(binding(x)) = x.id
∀x : BindingFault • Id(bindingFault(x)) = x.id
∀x : BindingOperation • Id(bindingOp(x)) = x.id
∀x : BindingMessageReference • Id(bindingMessageRef(x)) = x.id
∀x : BindingFaultReference • Id(bindingFaultRef(x)) = x.id
∀x : Service • Id(service(x)) = x.id
∀x : Endpoint • Id(endpoint(x)) = x.id
See Component, ID, Description, ElementDeclaration, TypeDefinition, Interface, InterfaceFault, InterfaceOperation, InterfaceMessageReference, InterfaceFaultReference, Feature, Property, Binding, BindingFault, BindingOperation, BindingMessageReference, BindingFaultReference, Service, Endpoint.

The Id function is an example of a Z Notation axiomatic definition. An axiomatic definition declares an object and then characterises it with a set of axioms or logical constraints that it satisfies. In this case, the Id function is constrained by giving its value on each possible type of component, which uniquely defines it.

ComponentModel1  [ show all ]  [ hide all ]

A component model is a set of uniquely identified components that satisfy a set of validity constraints which are described in the following sections.

Let ComponentModel1 be the base set of component models. This set will be further constrained in the following sections:

  • Let components be the set of components in the component model.

  • Let componentIds be the set of identifiers of components in the component model.

ComponentModel1
components :ℙComponent
componentIds :ℙID
∀x, y : components •
      Id(x) = Id(y)⇒x = y
componentIds = { x : components • Id(x) }
See Component, Id.

  • No two components have the same identifier.

IdentifierValid  [ show all ]  [ hide all ]

An identifier is valid if it is the identifier of a component in the component model.

Let IdentifierValid express this validity constraint:

IdentifierValid
ComponentModel1
Identifier
id∈componentIds
See ComponentModel1, Identifier.
InterfaceComponents  [ show all ]  [ hide all ]

In order to express the additional contraints on the component model, it is convenient to define the subsets of components of each type and their corresponding subsets of identifiers.

Let InterfaceComponents define the subsets of components that are related to the Interface component:

InterfaceComponents
ComponentModel1
interfaceComps :ℙInterface
interfaceFaultComps :ℙInterfaceFault
interfaceOpComps :ℙInterfaceOperation
interfaceMessageRefComps :ℙInterfaceMessageReference
interfaceFaultRefComps :ℙInterfaceFaultReference
interfaceComps = { x : Interface |
      interface(x)∈components }
interfaceFaultComps = { x : InterfaceFault |
      interfaceFault(x)∈components }
interfaceOpComps = { x : InterfaceOperation |
      interfaceOp(x)∈components }
interfaceMessageRefComps = { x : InterfaceMessageReference |
      interfaceMessageRef(x)∈components }
interfaceFaultRefComps = { x : InterfaceFaultReference |
      interfaceFaultRef(x)∈components }
See ComponentModel1, Interface, InterfaceFault, InterfaceOperation, InterfaceMessageReference, InterfaceFaultReference.

The definition of InterfaceComponents is an example of Z Notation schema inclusion. In Z schema inclusion all the fields and constraints of the included Z schema, e.g. ComponentModel1 are added to the including Z schema, e.g. InterfaceComponents.

InterfaceComponentIds  [ show all ]  [ hide all ]

Let InterfaceComponentIds define the subsets of component identifiers that are related to the Interface component:

InterfaceComponentIds
InterfaceComponents
interfaceIds :ℙID
interfaceFaultIds :ℙID
interfaceOpIds :ℙID
interfaceMessageRefIds :ℙID
interfaceFaultRefIds :ℙID
interfaceIds = { x : interfaceComps • x.id }
interfaceFaultIds = { x : interfaceFaultComps • x.id }
interfaceOpIds = { x : interfaceOpComps • x.id }
interfaceMessageRefIds = { x : interfaceMessageRefComps • x.id }
interfaceFaultRefIds = { x : interfaceFaultRefComps • x.id }
See InterfaceComponents, ID.
BindingComponents  [ show all ]  [ hide all ]

Let BindingComponents define the subsets of components that are related to the Binding component:

BindingComponents
ComponentModel1
bindingComps :ℙBinding
bindingFaultComps :ℙBindingFault
bindingOpComps :ℙBindingOperation
bindingMessageRefComps :ℙBindingMessageReference
bindingFaultRefComps :ℙBindingFaultReference
bindingComps = { x : Binding |
      binding(x)∈components }
bindingFaultComps = { x : BindingFault |
      bindingFault(x)∈components }
bindingOpComps = { x : BindingOperation |
      bindingOp(x)∈components }
bindingMessageRefComps = { x : BindingMessageReference |
      bindingMessageRef(x)∈components }
bindingFaultRefComps = { x : BindingFaultReference |
      bindingFaultRef(x)∈components }
See ComponentModel1, Binding, BindingFault, BindingOperation, BindingMessageReference, BindingFaultReference.
BindingComponentIds  [ show all ]  [ hide all ]

Let BindingComponentIds define the subsets of component identifiers that are related to the Binding component:

BindingComponentIds
BindingComponents
bindingIds :ℙID
bindingFaultIds :ℙID
bindingOpIds :ℙID
bindingMessageRefIds :ℙID
bindingFaultRefIds :ℙID
bindingIds = { x : bindingComps • x.id }
bindingFaultIds = { x : bindingFaultComps • x.id }
bindingOpIds = { x : bindingOpComps • x.id }
bindingMessageRefIds = { x : bindingMessageRefComps • x.id }
bindingFaultRefIds = { x : bindingFaultRefComps • x.id }
See BindingComponents, ID.
ServiceComponents  [ show all ]  [ hide all ]

Let ServiceComponents define the subsets of components that are related to the Service component:

  • Let serviceComps be the subset of Service components.

  • Let endpointComps be the subset of Endpoint components.

ServiceComponents
ComponentModel1
serviceComps :ℙService
endpointComps :ℙEndpoint
serviceComps = { x : Service |
      service(x)∈components }
endpointComps = { x : Endpoint |
      endpoint(x)∈components }
See ComponentModel1, Service, Endpoint.
ServiceComponentIds  [ show all ]  [ hide all ]

Let ServiceComponentIds define the subsets of component identifiers that are related to the Service component:

  • Let serviceIds be the subset of Service component identifiers.

  • Let endpointIds be the subset of Endpoint component identifiers.

ServiceComponentIds
ServiceComponents
serviceIds :ℙID
endpointIds :ℙID
serviceIds = { x : serviceComps • x.id }
endpointIds = { x : endpointComps • x.id }
See ServiceComponents, ID.
OtherComponents  [ show all ]  [ hide all ]

Let OtherComponents define the subsets of the other component types:

  • Let descriptionComps be the subset of Description components.

  • Let elementDeclComps be the subset of Element Declaration components.

  • Let typeDefComps be the subset of Type Definition components.

  • Let featureComps be the subset of Feature components.

  • Let propertyComps be the subset of Property components.

OtherComponents
ComponentModel1
descriptionComps :ℙDescription
elementDeclComps :ℙElementDeclaration
typeDefComps :ℙTypeDefinition
featureComps :ℙFeature
propertyComps :ℙProperty
descriptionComps = { x : Description |
      description(x)∈components }
elementDeclComps = { x : ElementDeclaration |
      elementDecl(x)∈components }
typeDefComps = { x : TypeDefinition |
      typeDef(x)∈components }
featureComps = { x : Feature |
      feature(x)∈components }
propertyComps = { x : Property |
      property(x)∈components }
See ComponentModel1, Description, ElementDeclaration, TypeDefinition, Feature, Property.
OtherComponentIds  [ show all ]  [ hide all ]

Let OtherComponentIds define the subsets of other component identifiers:

  • Let descriptionIds be the subset of Description component identifiers.

  • Let elementDeclIds be the subset of Element Declaration component identifiers.

  • Let typeDefIds be the subset of Type Definition component identifiers.

  • Let featureIds be the subset of Feature component identifiers.

  • Let propertyIds be the subset of Property component identifiers.

OtherComponentIds
OtherComponents
descriptionIds :ℙID
elementDeclIds :ℙID
typeDefIds :ℙID
featureIds :ℙID
propertyIds :ℙID
descriptionIds = { x : descriptionComps • x.id }
elementDeclIds = { x : elementDeclComps • x.id }
typeDefIds = { x : typeDefComps • x.