Table of contents

Appendices

2 Component Model

This section describes the conceptual model of WSDL as a set of components with attached properties, which collectively describe a Web service. Each subsection herein describes a different type of component, its defined properties, and its representation as an XML Infoset [XMLInfoSet].

Components are typed collections of properties that correspond to different aspects of Web services.

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 independent of any particular serialization of the component model. In order to avoid creating an implicit dependency on a particular serialization, this specification defines its own set of simple types for use by component definitions, rather than reusing an existing one (say [XMLSchemaP2]). By convention, those types are defined in the http://www.w3.org/2004/08/wsdl-simple-types namespace and references to them use the wsdls prefix, see [Definition of the Simple Types Used in the Component Model]. All the value spaces of all simple types used by the the component model are a superset of the value spaces of the XML Schema simple types with the same name, i.e. every xs:string is also a wsdls:string (but the opposite is not true). Hence, for brevity, in the sections describing the mapping from the XML Infoset representation of a WSDL document to its component model we use "actual values" as defined by the XML Schema specification [XMLSchemaP2] as if they were members of the value space of the corresponding WSDL-defined simple types. So, for instance, we talk of "assigning the actual value of the name attribute information item (a xs:string) "to the {name} property (of type wsdls:string)" of a certain component.

In addition to the direct XML Infoset representation described here, the component model allows components external to the Infoset through the mechanisms described in [Modularizing WSDL descriptions].

A component model can be extracted from a given XML Infoset which conforms to the XML Schema for WSDL 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 [Modularizing WSDL descriptions].

This document does not specify a means of producing an XML Infoset representation from a given set of WSDL components. Furthermore, given a particular serialization, not all valid sets of components need be serializable to it. For instance, due to the use in the component model of types that cannot be described using XML schema (.e.g wsdls:string), it is possible to come up with a valid set of WSDL components that cannot be serialized as an XML 1.0 document.