1.1 Scope
This International Standard defines the WS-I Simple SOAP Binding Profile 1.0
(hereafter, "Profile"), consisting of a set of non-proprietary Web services
specifications, along with clarifications to and amplifications of those specifications
which promote interoperability.
Section 1 introduces the Profile, and explains its relationships to other profiles.
Section 2, "Profile Conformance", explains what it means to be conformant to the
Profile.
Each subsequent section addresses a component of the Profile, and consists of
two parts: an overview detailing the component specifications and their
extensibility points, followed by subsections that address individual parts of the
component specifications. Note that there is no relationship between the section
numbers in this International Standard and those in the referenced specifications.
1.2 Relationships to Other Profiles
This Profile is derived from those Basic Profile 1.0 requirements related to the
serialization of the envelope and its representation in the message, incorporating
any errata to date. These requirements have been factored out of the Basic Profile
1.1 to enable other Profiles to be composable with it.
A combined claim of conformance to both the Basic Profile 1.1 and the Simple
SOAP Binding Profile 1.0 is roughly equivalent to a claim of conformance to the
Basic Profile 1.0.
This Profile composed with the Basic Profile 1.1 supersedes the Basic Profile 1.0.
1.3 Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Normative statements of requirements in the Profile (i.e., those impacting
conformance, as outlined in "Conformance Requirements") are presented in the
following manner:
RnnnnStatement text here.
where "nnnn" is replaced by a number that is unique among the requirements in
the Profile, thereby forming a unique requirement identifier.
Requirement identifiers can be considered to be namespace qualified, in such a
way as to be compatible with QNames from Namespaces in XML. If there is no
explicit namespace prefix on a requirement's identifier (e.g., "R9999" as opposed
to "bp10:R9999"), it should be interpreted as being in the namespace identified by
the conformance URI of the document section it occurs in. If it is qualified, the
prefix should be interpreted according to the namespace mappings in effect, as
documented below.
Some requirements clarify the referenced specification(s), but do not place
additional constraints upon implementations. For convenience, clarifications are
annotated in the following manner: C
Some requirements are derived from ongoing standardization work on the
referenced specification(s). For convenience, such forward-derived statements are
annotated in the following manner: xxxx, where "xxxx" is an identifier for the
specification (e.g., "WSDL20" for WSDL Version 2.0). Note that because such
work was not complete when this document was publiished, the specification that
the requirement is derived from may change; this information is included only as a
convenience to implementers.
This specification uses a number of namespace prefixes throughout; their
associated URIs are listed below. Note that the choice of any namespace prefix is
arbitrary and not semantically significant.
• wsdl - "http://schemas.xmlsoap.org/wsdl/"
• soapbind - "http://schemas.xmlsoap.org/wsdl/soap/"
• uddi - "urn:uddi-org:api_v2"
1.4 Profile Identification and Versioning
This document is identified by a name (in this case, Simple SOAP Binding Profile)
and a version number (here, 1.0). Together, they identify a particular profile
instance.
Version numbers are composed of a major and minor portion, in the form
"major.minor". They can be used to determine the precedence of a profile
instance; a higher version number (considering both the major and minor
components) indicates that an instance is more recent, and therefore supersedes
earlier instances.
Instances of profiles with the same name (e.g., "Example Profile 1.1" and
"Example Profile 5.0") address interoperability problems in the same general
scope (although some developments may require the exact scope of a profile to
change between instances).
One can also use this information to determine whether two instances of a profile
are backwards-compatible; that is, whether one can assume that conformance to
an earlier profile instance implies conformance to a later one. Profile instances
with the same name and major version number (e.g., "Example Profile 1.0" and
"Example Profile 1.1") MAY be considered compatible. Note that this does not
imply anything about compatibility in the other direction; that is, one cannot
assume that conformance with a later profile instance implies conformance to an
earlier one.