oSIST ISO/IEC DIS 29361:2007

SLOVENSKI STANDARD
oSIST ISO/IEC DIS 29361:2007
01-julij-2007
,QIRUPDFLMVNDWHKQRORJLMD2VQRYQLSURILOUD]OLþLFD
Information technology — Basic Profile Version 1.1
Technologies de l'information — Version 1.1 de profil de base
Ta slovenski standard je istoveten z:
ICS:
35.100.05 9HþVORMQHXSRUDEQLãNH Multilayer applications
UHãLWYH
oSIST ISO/IEC DIS 29361:2007 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
DRAFT INTERNATIONAL STANDARD ISO/IEC 29361
Attributed to ISO/IEC JTC 1 by the Central Secretariat (see page iii)

Voting begins on Voting terminates on
2006-12-18 2007-06-18
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION • МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ • ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION • МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОММИСИЯ • COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE


PUBLICLY AVAILABLE SPECIFICATION PROCEDURE
Information technology — Basic Profile Version 1.1
Technologies de l'information — Version 1.1 de profil de base
ICS 35.100.05
In accordance with the provisions of Council Resolution 21/1986 this DIS is circulated in the
English language only.
Conformément aux dispositions de la Résolution du Conseil 21/1986, ce DIS est distribué en
version anglaise seulement.

This Publicly Available Specification (PAS) is being submitted for Fast-track processing in
accordance with the provisions of ISO/IEC JTC 1 Directives.


THIS DOCUMENT IS A DRAFT CIRCULATED FOR COMMENT AND APPROVAL. IT IS THEREFORE SUBJECT TO CHANGE AND MAY NOT BE
REFERRED TO AS AN INTERNATIONAL STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS BEING ACCEPTABLE FOR INDUSTRIAL, TECHNOLOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON OCCASION HAVE TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL TO BECOME
STANDARDS TO WHICH REFERENCE MAY BE MADE IN NATIONAL REGULATIONS.
International Organization for Standardization, 2006
©
International Electrotechnical Commission, 2006

---------------------- Page: 2 ----------------------
ISO/IEC DIS 29361
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted
under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic,
photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO's
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO/IEC 2006 — All rights reserved

---------------------- Page: 3 ----------------------
ISO/IEC DIS 29361
NOTE FROM ITTF
This draft International Standard is submitted for JTC 1 national body vote under the Fast-Track Procedure.
In accordance with Resolution 30 of the JTC 1 Berlin Plenary 1993, the proposer of this document recommends
assignment of ISO/IEC 29361 to JTC 1.
See also explanatory report.
“FAST-TRACK” PROCEDURE
1  Any P-member and any Category A liaison organization of ISO/IEC JTC 1 may propose that an existing
standard from any source be submitted directly for vote as a DIS. The criteria for proposing an existing
standard for the fast-track procedure are a matter for each proposer to decide.
2  The proposal shall be received by the ITTF which will take the following actions.
2.1  To settle the copyright and/or trade mark situation with the proposer, so that the proposed text can be
freely copied and distributed within JTC 1 without restriction.
2.2  To assess in consultation with the JTC 1 secretariat which SC is competent for the subject covered by
the proposed standard and to ascertain that there is no evident contradiction with other International
Standards.
2.3  To distribute the text of the proposed standard as a DIS. In case of particularly bulky documents the ITTF
may demand the necessary number of copies from the proposer.
3  The period for combined DIS voting shall be six months. In order to be accepted the DIS must be
supported by 75 % of the votes cast (abstention is not counted as a vote) and by two-thirds of the P-members
voting of JTC 1.
4  At the end of the voting period, the comments received, whether editorial only or technical, will be dealt
with by a working group appointed by the secretariat of the relevant SC.
5  If, after the deliberations of this WG, the requirements of 3 above are met, the amended text shall be sent
to the ITTF by the secretariat of the relevant SC for publication as an International Standard.
If it is impossible to agree to a text meeting the above requirements, the proposal has failed and the procedure
is terminated.
In either case the WG shall prepare a full report which will be circulated by the ITTF.
6  If the proposed standard is accepted and published, its maintenance will be handled by JTC 1.

© ISO/IEC 2006 — All rights reserved iii

---------------------- Page: 4 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
Basic Profile Version 1.1
Final Material
2006-04-10
This version:
http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html
Latest version:
http://www.ws-i.org/Profiles/BasicProfile-1.1.html
Errata for this Version:
http://www.ws-i.org/Profiles/BasicProfile-1.1-errata-2006-04-10.html
Editors:
Keith Ballinger, Microsoft (1.0)
David Ehnebuske, IBM (1.0)
Christopher Ferris, IBM
Martin Gudgin, Microsoft (1.0)
Canyang Kevin Liu, SAP
Mark Nottingham, BEA Systems
Prasad Yendluri, webMethods
Administrative contact:
secretary@ws-i.org
Copyright © 2002-2006 by The Web Services-Interoperability Organization (WS-I) and Certain of its
Members. All Rights Reserved.
Abstract
This document defines the WS-I Basic Profile 1.1, consisting of a set of non-proprietary Web
services specifications, along with clarifications, refinements, interpretations and amplifications of
those specifications which promote interoperability
Status of this Document
This is a final specification. Please refer to the errata, which may include normative corrections to it.
Notice
The material contained herein is not a license, either expressly or impliedly, to any intellectual
property owned or controlled by any of the authors or developers of this material or WS-I. The
material contained herein is provided on an "AS IS" basis and to the maximum extent permitted by
1 of 46 7/10/2006 10:24 PM

---------------------- Page: 5 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and
developers of this material and WS-I hereby disclaim all other warranties and conditions, either
express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or
conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of
responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO,
THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET
POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH
REGARD TO THIS MATERIAL.
IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE
TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR
SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER
CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR
ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY
HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
Feedback
If there are areas in this specification that could be clearer, or if errors or omissions are identified,
WS-I would like to be notified in order to provide the best possible interoperability guidance.
By sending email, or otherwise communicating with WS-I, you (on behalf of yourself if you are an
individual, and your company if you are providing Feedback on behalf of the company) will be
deemed to have granted to WS-I, the members of WS-I, and other parties that have access to your
Feedback, a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license
to use, disclose, copy, license, modify, sublicense or otherwise distribute and exploit in any manner
whatsoever the Feedback you provide regarding the work. You acknowledge that you have no
expectation of confidentiality with respect to any Feedback you provide. You represent and warrant
that you have rights to provide this Feedback, and if you are providing Feedback on behalf of a
company, you represent and warrant that you have the rights to provide Feedback on behalf of your
company. You also acknowledge that WS-I is not required to review, discuss, use, consider or in any
way incorporate your Feedback into future versions of its work. If WS-I does incorporate some or all
of your Feedback in a future version of the work, it may, but is not obligated to include your name
(or, if you are identified as acting on behalf of your company, the name of your company) on a list of
contributors to the work. If the foregoing is not acceptable to you and any company on whose behalf
you are acting, please do not provide any Feedback.
Feedback on this document should be directed to wsbasic_comment@ws-i.org.
Table of Contents
1. Introduction
1.1. Relationships to Other Profiles
1.2. Changes from Basic Profile Version 1.0
1.3. Guiding Principles
1.4. Notational Conventions
1.5. Profile Identification and Versioning
2. Profile Conformance
2.1. Conformance Requirements
2.2. Conformance Targets
2.3. Conformance Scope
2.4. Claiming Conformance
3. Messaging
2 of 46 7/10/2006 10:24 PM

---------------------- Page: 6 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
3.1. SOAP Envelopes
3.1.1. SOAP Envelope Structure
3.1.2. SOAP Envelope Namespace
3.1.3. SOAP Body Namespace Qualification
3.1.4. Disallowed Constructs
3.1.5. SOAP Trailers
3.1.6. SOAP encodingStyle Attribute
3.1.7. SOAP mustUnderstand Attribute
3.1.8. xsi:type Attributes
3.1.9. SOAP1.1 attributes on SOAP1.1 elements
3.2. SOAP Processing Model
3.2.1. Mandatory Headers
3.2.2. Generating mustUnderstand Faults
3.2.3. SOAP Fault Processing
3.3. SOAP Faults
3.3.1. Identifying SOAP Faults
3.3.2. SOAP Fault Structure
3.3.3. SOAP Fault Namespace Qualification
3.3.4. SOAP Fault Extensibility
3.3.5. SOAP Fault Language
3.3.6. SOAP Custom Fault Codes
3.4. Use of SOAP in HTTP
3.4.1. HTTP Protocol Binding
3.4.2. HTTP Methods and Extensions
3.4.3. SOAPAction HTTP Header
3.4.4. HTTP Success Status Codes
3.4.5. HTTP Redirect Status Codes
3.4.6. HTTP Client Error Status Codes
3.4.7. HTTP Server Error Status Codes
3.4.8. HTTP Cookies
4. Service Description
4.1. Required Description
4.2. Document Structure
4.2.1. WSDL Schema Definitions
4.2.2. WSDL and Schema Import
4.2.3. WSDL Import location Attribute Structure
4.2.4. WSDL Import location Attribute Semantics
4.2.5. Placement of WSDL import Elements
4.2.6. XML Version Requirements
4.2.7. XML Namespace declarations
4.2.8. WSDL and the Unicode BOM
4.2.9. Acceptable WSDL Character Encodings
4.2.10. Namespace Coercion
4.2.11. WSDL documentation Element
4.2.12. WSDL Extensions
4.3. Types
4.3.1. QName References
4.3.2. Schema targetNamespace Structure
4.3.3. soapenc:Array
4.3.4. WSDL and Schema Definition Target Namespaces
4.4. Messages
4.4.1. Bindings and Parts
4.4.2. Bindings and Faults
4.4.3. Declaration of part Elements
4.5. Port Types
4.5.1. Ordering of part Elements
3 of 46 7/10/2006 10:24 PM

---------------------- Page: 7 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
4.5.2. Allowed Operations
4.5.3. Distinctive Operations
4.5.4. parameterOrder Attribute Construction
4.5.5. Exclusivity of type and element Attributes
4.6. Bindings
4.6.1. Use of SOAP Binding
4.7. SOAP Binding
4.7.1. Specifying the transport Attribute
4.7.2. HTTP Transport
4.7.3. Consistency of style Attribute
4.7.4. Encodings and the use Attribute
4.7.5. Multiple Bindings for portType Elements
4.7.6. Operation Signatures
4.7.7. Multiple Ports on an Endpoint
4.7.8. Child Element for Document-Literal Bindings
4.7.9. One-Way Operations
4.7.10. Namespaces for soapbind Elements
4.7.11. Consistency of portType and binding Elements
4.7.12. Describing headerfault Elements
4.7.13. Enumeration of Faults
4.7.14. Type and Name of SOAP Binding Elements
4.7.15. name Attribute on Faults
4.7.16. Omission of the use Attribute
4.7.17. Default for use Attribute
4.7.18. Consistency of Envelopes with Descriptions
4.7.19. Response Wrappers
4.7.20. Part Accessors
4.7.21. Namespaces for Children of Part Accessors
4.7.22. Required Headers
4.7.23. Allowing Undescribed Headers
4.7.24. Ordering Headers
4.7.25. Describing SOAPAction
4.7.26. SOAP Binding Extensions
4.8. Use of XML Schema
5. Service Publication and Discovery
5.1. bindingTemplates
5.2. tModels
6. Security
6.1. Use of HTTPS
Appendix A: Referenced Specifications
Appendix B: Extensibility Points
Appendix C: Defined Terms
Appendix D: Acknowledgements
1. Introduction
This document defines the WS-I Basic Profile 1.1 (hereafter, "Profile"), consisting of a set of
non-proprietary Web services specifications, along with clarifications, refinements, interpretations
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
4 of 46 7/10/2006 10:24 PM

---------------------- Page: 8 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
subsections that address individual parts of the component specifications. Note that there is no
relationship between the section numbers in this document and those in the referenced
specifications.
1.1 Relationships to Other Profiles
This Profile is derived from the Basic Profile 1.0 by incorporating any errata to date and separating
out those requirements related to the serialization of envelopes and their representation in
messages. Such requirements are now part of the Simple SOAP Binding Profile 1.0, identified with a
separate conformance claim. This separation is made to facilitate composability of Basic Profile 1.1
with any profile that specifies envelope serialization, including the Simple SOAP Binding Profile 1.0
and the Attachments Profile 1.0. 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 plus published errata.
This Profile, composed with the Simple SOAP Binding Profile 1.0 supercedes the Basic Profile 1.0.
The Attachments Profile 1.0 adds support for SOAP with Attachments, and is intended to be used in
combination with this Profile.
1.2 Changes from Basic Profile Version 1.0
This specification is derived from the Basic Profile Version 1.0, and incorporates published errata
against that specification. The most notable changes are:
MESSAGE conformance target - Some requirements that had a MESSAGE conformance
target in BP1.0 now use a new target, ENVELOPE. This facilitates alternate serialisations of
the message, such as that described in the Attachments Profile.
SOAP Binding - Requirements relating to the SOAP binding's serialization of the message
have been moved to the Simple SOAP Binding Profile to facilitate other serializations.
1.3 Guiding Principles
The Profile was developed according to a set of principles that, together, form the philosophy of the
Profile, as it relates to bringing about interoperability. This section documents these guidelines.
No guarantee of interoperability
It is impossible to completely guarantee the interoperability of a particular service. However,
the Profile does address the most common problems that implementation experience has
revealed to date.
Application semantics
Although communication of application semantics can be facilitated by the technologies that
comprise the Profile, assuring the common understanding of those semantics is not addressed
by it.
Testability
When possible, the Profile makes statements that are testable. However, such testability is not
required. Preferably, testing is achieved in a non-intrusive manner (e.g., examining artifacts
"on the wire").
Strength of requirements
The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever feasible; if there
are legitimate cases where such a requirement cannot be met, conditional requirements (e.g.,
SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce
ambiguity and mismatches between implementations.
Restriction vs. relaxation
When amplifying the requirements of referenced specifications, the Profile may restrict them,
5 of 46 7/10/2006 10:24 PM

---------------------- Page: 9 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
but does not relax them (e.g., change a MUST to a MAY).
Multiple mechanisms
If a referenced specification allows multiple mechanisms to be used interchangeably, the
Profile selects those that are well-understood, widely implemented and useful. Extraneous or
underspecified mechanisms and extensions introduce complexity and therefore reduce
interoperability.
Future compatibility
When possible, the Profile aligns its requirements with in-progress revisions to the
specifications it references. This aids implementers by enabling a graceful transition, and
assures that WS-I does not 'fork' from these efforts. When the Profile cannot address an issue
in a specification it references, this information is communicated to the appropriate body to
assure its consideration.
Compatibility with deployed services
Backwards compatibility with deployed Web services is not a goal for the Profile, but due
consideration is given to it; the Profile does not introduce a change to the requirements of a
referenced specification unless doing so addresses specific interoperability issues.
Focus on interoperability
Although there are potentially a number of inconsistencies and design flaws in the referenced
specifications, the Profile only addresses those that affect interoperability.
Conformance targets
Where possible, the Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP
messages) rather than the producing or consuming software's behaviors or roles. Artifacts are
concrete, making them easier to verify and therefore making conformance easier to
understand and less error-prone.
Lower-layer interoperability
The Profile speaks to interoperability at the application layer; it assumes that interoperability of
lower-layer protocols (e.g., TCP, IP, Ethernet) is adequate and well-understood. Similarly,
statements about application-layer substrate protocols (e.g., SSL/TLS, HTTP) are only made
when there is an issue affecting Web services specifically; WS-I does not attempt to assure
the interoperability of these protocols as a whole. This assures that WS-I's expertise in and
focus on Web services standards is used effectively.
1.4 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:
Rnnnn Statement 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
6 of 46 7/10/2006 10:24 PM

---------------------- Page: 10 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
C
upon implementations. For convenience, clarifications are annotated in the following manner:
Some requirements are derived from ongoing standardization work on the referenced
specification(s). For convenience, such forward-derived statements are annotated in the following
xxxx
manner: , 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 published, the
specification that the requirement is derived from may change; this information is included only as a
convenience to implementers.
Extensibility points in underlying specifications (see "Conformance Scope") are presented in a
similar manner:
Ennnn Extensibility Point Name - Description
where "nnnn" is replaced by a number that is unique among the extensibility points in the Profile. As
with requirement statements, extensibility statements can be considered namespace-qualified.
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.
soap - "http://schemas.xmlsoap.org/soap/envelope/"
xsi - "http://www.w3.org/2001/XMLSchema-instance"
xsd - "http://www.w3.org/2001/XMLSchema"
soapenc - "http://schemas.xmlsoap.org/soap/encoding/"
wsdl - "http://schemas.xmlsoap.org/wsdl/"
soapbind - "http://schemas.xmlsoap.org/wsdl/soap/"
uddi - "urn:uddi-org:api_v2"
1.5 Profile Identification and Versioning
This document is identified by a name (in this case, Basic Profile) and a version number (here, 1.1).
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.
2 Profile Conformance
Conformance to the Profile is defined by adherence to the set of requirements defined for a specific
target, within the scope of the Profile. This section explains these terms and describes how
conformance is defined and used.
7 of 46 7/10/2006 10:24 PM

---------------------- Page: 11 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
2.1 Conformance Requirements
Requirements state the criteria for conformance to the Profile. They typically refer to an existing
specification and embody refinements, amplifications, interpretations and clarifications to it in order
to improve interoperability. All requirements in the Profile are considered normative, and those in the
specifications it references that are in-scope (see "Conformance Scope") should likewise be
considered normative. When requirements in the Profile and its referenced specifications contradict
each other, the Profile 's requirements take precedence for purposes of Profile conformance.
Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD) indicate the nature of
the requirement and its impact on conformance. Each requirement is individually identified (e.g.,
R9999) for convenience.
For example;
R9999 WIDGETs SHOULD be round in shape.
This requirement is identified by "R9999", applies to the target WIDGET (see below), and places a
conditional requirement upon widgets; i.e., although this requirement must be met to maintain
conformance in most cases, there are some situations where there may be valid reasons for it not
being met (which are explained in the requirement itself, or in its accompanying text).
Each requirement statement contains exactly one requirement level keyword (e.g., "MUST") and one
conformance target keyword (e.g., "MESSAGE"). The conformance target keyword appears in bold
text (e.g. "MESSAGE"). Other conformance targets appearing in non-bold text are being used strictly
for their definition and NOT as a conformance target. Additional text may be included to illuminate a
requirement or group of requirements (e.g., rationale and examples); however, prose surrounding
requirement statements must not be considered in determining conformance.
Definitions of terms in the Profile are considered authoritative for the purposes of determining
conformance.
None of the requirements in the Profile, regardless of their conformance level, should be interpreted
as limiting the ability of an otherwise conforming implementation to apply security countermeasures
in response to a real or perceived threat (e.g., a denial of service attack).
2.2 Conformance Targets
Conformance targets identify what artifacts (e.g., SOAP message, WSDL description, UDDI registry
data) or parties (e.g., SOAP processor, end user) requirements apply to.
This allows for the definition of conformance in different contexts, to assure unambiguous
interpretation of the applicability of requirements, and to allow conformance testing of artifacts (e.g.,
SOAP messages and WSDL descriptions) and the behavior of various parties to a Web service
(e.g., clients and service instances).
Requirements' conformance targets are physical artifacts wherever possible, to simplify testing and
avoid ambiguity.
The following conformance targets are used in the Profile:
MESSAGE - protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP messages)
ENVELOPE - the serialization of the soap:Envelope element and its content
DESCRIPTION - descriptions of types, messages, interfaces and their concrete protocol and
data format bindings, and the network access points associated with Web services (e.g.,
WSDL descriptions) (from Basic Profile 1.0)
INSTANCE - software that implements a wsdl:port or a uddi:bindingTemplate (from Basic
8 of 46 7/10/2006 10:24 PM

---------------------- Page: 12 ----------------------
Basic Profile - Version 1.1 (Final) http://www.ws-i.org/Profiles/BasicProfile-1.1.html
Profile 1.0)
CONSUMER - software that invokes an INSTANCE (from Basic Profile 1.0)
SENDER - software that generates a message according to the protocol(s) associated with it
(from Basic Profile 1.0)
RECEIVER - software that consumes a message according to the protocol(s) associated with
it (e.g., SOAP processors) (from Basic Profile 1.0)
REGDATA - registry elements that are involved in the registration and discovery of Web
services (e.g. UDDI tModels) (from Basic Profile 1.0)
2.3 Conformance Scope
The scope of the Profile delineates the technologies that it addresses; in other words, the Profile
only attempts to improve interoperability within its own scope. Generally, the Profile's scope is
bounded by the specifications referenced by it.
The Profile's scope is further refined by extensibility points. Reference
...