Copyright © 2002-2010 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members. All Rights Reserved.
This document defines the WS-I Basic Profile 2.0, consisting of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability. It also contains a set of executable test assertions for assessing the conformance to the profile.
This document is a Working Group Draft; it has been accepted by the Working Group as reflecting the current state of discussions. It is a work in progress, and should not be considered authoritative or final; other documents may supersede this document.
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 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.
The Web Services-Interoperability Organization (WS-I) would like to receive input, suggestions and other feedback ("Feedback") on this work from a wide variety of industry participants to improve its quality over time.
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.
1. Introduction
1.1. Relationships to
Other Profiles
1.2. Guiding
Principles
1.3. Test
Assertions
1.4. Compatibility with Basic Profile 1.1 and
1.2
1.5. Notational
Conventions
1.6. 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
3.1. Message
Serialization
3.1.1. XML Envelope
Serialization
3.1.2. Unicode
BOMs
3.1.3. XML
Declarations
3.1.4. Character Encodings
3.1.5. XOP
Encoded Messages
3.2. SOAP
Envelopes
3.2.1. SOAP Envelope Structure
3.2.2. SOAP Body Namespace
Qualification
3.2.3. Disallowed Constructs
3.2.4. xsi:type Attributes
3.2.5. SOAP 1.2 attributes on
SOAP 1.2 elements
3.3. SOAP Processing
Model
3.3.1. SOAP Fault Processing
3.4. SOAP
Faults
3.4.1. Identifying SOAP Faults
3.5. Use of SOAP in
HTTP
3.5.1. HTTP Protocol Binding
3.5.2. Parameters on the
Content-Type MIME Header
3.5.3. HTTP Success Status
Codes
3.5.4. HTTP Redirect Status
Codes
3.5.5. HTTP
Cookies
3.5.6. Non-Addressable
Consumers and Instances
3.6. Use of URIs in
SOAP
3.6.1. Use of SOAP-defined
URIs
3.7. WS-Addressing
Support
3.7.1. Requiring WS-Addressing
SOAP headers
3.7.2.
NotUnderstood block in MustUnderstand Fault on WS-Addressing SOAP
headers
3.7.3. Use of
wsa:Action and WS-Addressing 1.0 - Metadata
3.7.4.
Valid Values for action Parameter on the Content-Type MIME header
When WS-Addressing is Used
3.7.5. SOAP Defined Faults Action
URI
3.7.6. Understanding
WS-Addressing SOAP Header Blocks
3.7.7. Ignored or Absent
WS-Addressing MAPs
3.7.8. Present and Understood
WS-Addressing MAPs
3.7.9. SOAP
MustUnderstand or VersionMismatch fault
Transmission
3.7.10.
Faulting Behavior with Present and Understood WS-Addressing
MAPs
3.7.11. [message id] and One-Way
Operations
3.7.12. Refusal to Honor
WS-Addressing MAPs
3.7.13. Use of Non-Anonymous Response
EPRs
3.7.14. Optionality of the wsa:To
header
3.7.15. Extending WSDL Endpoints
with an EPR
3.7.16. Combining
Synchronous and Asynchronous Operations
3.7.17. Conflicting Addressing
Policies
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.3.5. Multiple GED
Definitions with the same QName
4.3.6. Multiple Type
Definitions with the same QName
4.4. Messages
4.4.1. Bindings and Parts
4.4.2. Bindings and Faults
4.4.3. Unbound portType Element
Contents
4.4.4. Declaration of part
Elements
4.5. Port
Types
4.5.1. Ordering of part
Elements
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 wsoap12
Elements
4.7.11. Consistency of
portType and binding Elements
4.7.12. SOAP 1.2 Binding Extension
Correction
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
action Parameter on the Content-Type MIME Header
4.7.26. SOAPAction HTTP Header
4.7.27. SOAP Binding Extensions
4.8. Use of
@soapActionRequired in WSDL 1.1 SOAP 1.2 Binding
4.9. Use of XML
Schema
4.10. WS-Addressing
1.0 - Metadata
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: Normative
References
Appendix D: Defined Terms
Appendix E: Acknowledgements
This document defines the WS-I Basic Profile 2.0 (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 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.
This Profile is derived from the Basic Profile 1.1 by incorporating any errata to date and including those requirements related to the serialization of envelopes and their representation in messages from the Simple SOAP Binding Profile 1.0 .
This Profile is NOT intended to be composed with the Simple SOAP Binding 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.
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.
This profile document contains embedded Test Assertions (TA) that are associated with each normative profile requirement. In the HTML rendering of this document, these test assertions are accessible via a toggle link at the end of each requirement. When clicking on such a link, a table pops up that displays the TA parts. At the end of this table is another toggle link ("help-glossary") that displays an explanation glossary for the TA structure. In other formats of this document, the test assertions are grouped in an appendix not controlled by any link, in order to facilitate the printing of hard copies. The resulting set of test assertions embedded in this document represents a conformance test suite for the profile.
Release notes related to the test material included in this document are available here:
TESTING-RELEASE-NOTESNote Item: | Release Notes : 2009-08-26 |
---|---|
test suite |
The test assertions are scripted using XPath2.0 and are automatically processable using the version 2.0 of the WS-I Analyzer tools. Several requirements have been tagged "NOT_TESTABLE". This means that these requirements cannot be tested based on the technology choices (black-box testing, XPath scripting). Other requirements have been tagged "NOT_TESTED". This is the case for most optional requirements (SHOULD, MAY), and for most Extensibility points as well as for requirements targeting UDDI. Some requirements may also require Schema awareness (ability to process schemas) from the Analyzer test tool. As this conflicted with the ability to use several freely available XSLT20 processors that are not Schema aware, such requirements have been marked "NOT_TESTED" unless this verification was done by tools prior to creating the test log file, which would then just contain some metadata indicating the results of these schema-realted tests. Other requirements have been tagged "TESTABLE_SCENARIO_DEPENDENT". This is the case when a specific test scenario is needed in order to exercise the related test assertion, because the test assertion is designed to trigger only on specific input material, e.g. that is known to NEVER be recognizable by an endpoint. A subsequent version may cover untested requirements. In this profile, the core requirements for assessing interoperability of implementations have been initially targeted. |
test assertions notes |
Test assertions are not guaranteed to exhaustively cover every case where a profile requirement applies. In several instances, more than one test assertion is needed to address the various situations where a profile requirement applies. To learn more about the details of test assertion outcomes and how they are reported in the test report, see the glossary link that appears below each test assertion table. |
test log rules |
Test Log content conventions: The test assertions designed for this test suite are written to work over "test log" files that are assumed to follow some rules in their structure and content. These rules are more completely stated in the documentation associated with the log file description. Some of these rules are: - Every message in the log must be uniquely identified: it must have a unique pair of values for: {message/@conversation, message/@id}, where @id is unique within each conversation. Typically, a conversation is used to identify an HTTP connection and the group of messages over this connection. - A response message (for WSDL request-responses as well as RM lifecycle messages) always appears after the request message in the log file. - A wsa:RelatesTo reference always refers to a message that has been logged before. - A Fault message always appears after the message-in-error. - An RM acknowledgement always appears after the messages it acknowledges. - there should not be both a doc-lit and an rpc-lit bindings for the same portType. - imports must be resolved locally to the log file. |
The Basic Profile 2.0 is the first version of the WS-I Basic Profile that changes the version of SOAP in the profile scope from SOAP 1.1 to the W3C SOAP 1.2 Recommendation. As such, clients, servers and the artifacts that comprise a Basic Profile 1.0, 1.1 or 1.2 conformant application are inherently incompatible with an application that is conformant with the Basic Profile 2.0. However, in general, the Basic Profile WG members have tried to preserve in the Basic Profile 2.0 as much consistency with the guidance and constraints of the Basic Profile 1.0, 1.1 and 1.2 as possible. This has been in part facilitated by the fact that the WG tried to remain consistent in the guidance and constraints of the original Basic Profile with the decisions that were being made in the context of the W3C XML Protocols WG as they were concurrently working on the SOAP 1.2 specificatons. For the most part, issues that were resolved in the context of the development of the Basic Profile 1.0, 1.1 and 1.2 were not revisited.
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.
Requirements 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 for this Profile.
Extensibility points in underlying specifications (see "Conformance Scope") are presented in a similar manner:
EnnnnExtensibility 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 Profile supports multiple conformance targets. Requirements or sections specific to the use of a particular conformance target are annotated in the following manner: TARGET.
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.
This document is identified by a name (in this case, Basic Profile) and a version number (here, 2.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.
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.
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 Any WIDGET 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.
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).
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:
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. Referenced specifications often provide extension mechanisms and unspecified or open-ended configuration parameters; when identified in the Profile as an extensibility point, such a mechanism or parameter is outside the scope of the Profile, and its use or non-use is not relevant to conformance.
Note that the Profile may still place requirements on the use of an extensibility point. Also, specific uses of extensibility points may be further restricted by other profiles, to improve interoperability when used in conjunction with the Profile.
Because the use of extensibility points may impair interoperability, their use should be negotiated or documented in some fashion by the parties to a Web service; for example, this could take the form of an out-of-band agreement.
The Profile's scope is defined by the referenced specifications in Appendix A, as refined by the extensibility points in Appendix B.
Claims of conformance to the Profile can be made using the following mechanisms, as described in Conformance Claim Attachment Mechanisms, when the applicable Profile requirements associated with the listed targets have been met:
Claims of conformance for the Basic Profile 2.0 encompass the transport-independent and HTTP-specific requirements. Claims are separated into two disjoint parts and an aggregated claim for the complete Basic Profile: "CORE", "HTTP-TRANSPORT", and "COMPLETE". The Basic Profile 2.0 conformance claim URI(s) are:
"Basic Profile 2.0 Complete": Encompasses all the requirements in this Profile the transport-independent (CORE) and HTTP-specific transport-layer mechanisms (HTTP-TRANSPORT). For interoperability, this aggregated conformance claim URI that combines all requirements for "COMPLETE" is:
http://ws-i.org/profiles/basic-profile/2.0/complete
"Basic Profile 2.0 Core": Encompasses the transport-independent requirements only. The conformance claim URI allows this Profile to be reusable for application across multiple transports. No transport-specific requirements apply. The conformance claim URI for "CORE" is:
http://ws-i.org/profiles/basic-profile/2.0/core
"Basic Profile 2.0 HTTP-Transport": Encompasses the HTTP transport-dependent requirements only. The conformance claim URI includes the HTTP-specific transport layer requirements. The "HTTP-TRANSPORT" URI must be combined with the "CORE" URI and cannot be used in isolation. The conformance claim URI for "HTTP-TRANSPORT" is:
http://ws-i.org/profiles/basic-profile/2.0/http-transport
This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:
Test Assertion: | BP1901 |
---|---|
Description: | The soap:Envelope contains other header blocks. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | permitted |
Error Message: | Extensibility Point WARNING: The soap12:Envelope makes use of extra SOAP headers |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1904 |
---|---|
Description: | The soap12:Envelope contains @role with unspecified values. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | permitted |
Error Message: | Extensibility Point WARNING: The soap12:Envelope contains @role with unspecified values |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1905 |
---|---|
Description: | The soap12:Envelope contains a Fault with unspecified Detail content. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | permitted |
Error Message: | Extensibility Point WARNING: The soap12:Fault makes use of optional Detail element |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The profile is intended to compose with mechanisms currently under development to describe whether messages are encoded as SIMPLE_SOAP_MESSAGEs or XOP_ENCODED_MESSAGEs. As such it does not mandate that both of those encodings be supported for any given operation. Indeed, neither of these encodings need be supported if an alternate encoding such as that described in the Attachments Profile 1.0 is used.
SOAP 1.2 defines an XML structure for serializing messages, the envelope. The Profile places the following constraints on the use and serialization of the soap12:Envelope element and its content:
This Profile allows for the use of protocol bindings other than HTTP. Section 2.2 identifies the use of Simple SOAP and XOP encoded messages using HTTP. Section 3.1 identifies how encoding is handled for HTTP only. RFC 2616 and RFC 3023 provide guidance for HTTP. If another transport protocol is used, the responsibility for defining how to handle transport-specific features (e.g. content encoding) falls to the specification of the binding of SOAP to that transport protocol.
This section of the Profile incorporates the following specifications by reference:
R9701 An ENVELOPE MUST be serialized as XML 1.0. CORE TESTABLE BP1019
Test Assertion: | BP1019 |
---|---|
Description: | The soap12:Envelope in the message is a well-formed XML 1.0 document. |
Target: |
|
co-Target: metadata |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The soap12:Envelope does not conform to XML 1.0. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
XML 1.0 allows UTF-8 encoding to include a BOM; therefore, receivers of envelopes must be prepared to accept them. The BOM is mandatory for XML encoded as UTF-16.
R4001 A RECEIVER MUST accept envelopes that include the Unicode Byte Order Mark (BOM). CORE NOT_TESTABLE
Presence or absence of an XML declaration does not affect interoperability. Certain implementations might always precede their XML serialization with the XML declaration.
R1010 A RECEIVER MUST accept messages with envelopes that contain an XML Declaration. CORE TESTABLE BP1015
Test Assertion: | BP1015 |
---|---|
Description: | A receiver must not fault messages with envelopes that contain an XML Declaration. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A soap Fault has been generated when receiving a message with an XML declaration: verify that this Fault has another cause - it must not be caused by the XML declaration. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The Profile requires XML processors to support the "UTF-8" and "UTF-16" character encodings, in order to aid interoperability.
To improve interoperabilitry, the "charset" parameter of Content-Type HTTP header field must be used to determine the correct character encoding of the message.
As this Profile allows the use of protocol bindings other than HTTP, the transport is responsible for defining how encoding is handled as specified in Section 2.2 for Simple SOAP and XOP encoded messages using HTTP. This applies to this section and Section 3.1.5 .
R1012 An ENVELOPE MUST be serialized using either UTF-8 or UTF-16 character encoding. CORE TESTABLE BP1018
Test Assertion: | BP1018 |
---|---|
Description: | The logged SOAP envelope is a UTF-8 transcript of an envelope originally encoded as UTF-8 or UTF-16. The HTTP Content-Type header's charset value is either UTF-8 or UTF-16. Looking at the messageContent element of the logged message, either (1) it has a BOM attribute which maps the charset value in the Content-Type header, or (2) it has it has an XML declaration which matches the charset value in the Content-Type header, or (3) there is no BOM attribute and no XML declaration, and the charset value is UTF-8. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | Either (1a) the message contains a Content-Type header but no charset value, or (1b) the charset value is neither UTF-8 nor UTF-16, or (2) there is a BOM attribute in the messageContent element, but its value does not match the charset value, or (3) there is an XML declaration, and the charset value does not match its value, or (4) there is no BOM attribute, no XML declaration, and the charset value in Content-Type header is not UTF-8. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1018 A SIMPLE_SOAP_MESSAGE MUST indicate the correct character encoding, using the "charset" parameter. CORE TESTABLE BP1018
Test Assertion: | BP1018 |
---|---|
Description: | The logged SOAP envelope is a UTF-8 transcript of an envelope originally encoded as UTF-8 or UTF-16. The HTTP Content-Type header's charset value is either UTF-8 or UTF-16. Looking at the messageContent element of the logged message, either (1) it has a BOM attribute which maps the charset value in the Content-Type header, or (2) it has it has an XML declaration which matches the charset value in the Content-Type header, or (3) there is no BOM attribute and no XML declaration, and the charset value is UTF-8. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | Either (1a) the message contains a Content-Type header but no charset value, or (1b) the charset value is neither UTF-8 nor UTF-16, or (2) there is a BOM attribute in the messageContent element, but its value does not match the charset value, or (3) there is an XML declaration, and the charset value does not match its value, or (4) there is no BOM attribute, no XML declaration, and the charset value in Content-Type header is not UTF-8. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1019 A RECEIVER MUST ignore the encoding pseudo-attribute of the envelope's XML declaration. CORE NOT_TESTABLE
There are implementations that are apparently encoding the
action
parameter as a separate parameter of the
enclosing MIME multipart/related entity body's
Content-Type
header. The
multipart/related
media type specification does not
include an action
parameter, though it does permit
extensibility. Thus, the action
parameter on the
multipart/related
Content-Type
header has
no defined semantic. The correct encoding is to include the action
parameter inside the start-info
parameter of the
enclosing MIME multipart/related
entity body as well
as inside the type
parameter of the root part.
See Section 3.1.4 for conformance criteria when using HTTP.
R1020 A XOP_ENCODED_MESSAGE MUST include the
start-info
parameter in the Content-Type
header of the enclosing multipart/related
MIME entity
body. CORE TESTABLE BP1020
Test Assertion: | BP1020 |
---|---|
Description: | A XOP_ENCODED_MESSAGE MUST include the start-info parameter in the Content-Type header of the enclosing multipart/related MIME entity body. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The XOP_ENCODED_MESSAGE does not include the start-info parameter with proper @value. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1021 A XOP_ENCODED_MESSAGE SHOULD include the
full value of the type parameter from the root entity body part
inside the start-info
parameter of the enclosing
multipart/related
MIME entity body part's
Content-Type
header. CORE TESTABLE BP1021
Test Assertion: | BP1021 |
---|---|
Description: | A XOP_ENCODED_MESSAGE SHOULD include the full value of the type parameter from the root entity body part inside the start-info parameter of the enclosing multipart/related MIME entity body part's Content-Type header. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | The XOP_ENCODED_MESSAGE SHOULD include the full value of the type parameter |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1022 A RECEIVER MUST accept a XOP encoded
message that has the action
parameter, associated with
the SOAP message, encoded inside the start-info
parameter on the Content-Type
header of the enclosing
multipart/related
MIME entity body. CORE NOT_TESTABLE
R1023 A RECEIVER MAY accept a XOP encoded message
that has the action
parameter, associated with the
SOAP message, encoded as a separate parameter on the
Content-Type
header of the enclosing
multipart/related
MIME entity body. CORE NOT_TESTABLE
For example,
INCORRECT:
MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary; type="application/xop+xml"; start="<mymessage.xml@example.org>"; start-info="application/soap+xml"; action="ProcessData" --MIME_boundary Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml; action=\"ProcessData\"" Content-Transfer-Encoding: 8bit Content-ID: <mymessage.xml@example.org> ...
CORRECT:
MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary; type="application/xop+xml"; start="<mymessage.xml@example.org>"; start-info="application/soap+xml; action=\"ProcessData\"" Content-Description: A SOAP message with my pic and sig in it --MIME_boundary Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml; action=\"ProcessData\"" Content-Transfer-Encoding: 8bit Content-ID: <mymessage.xml@example.org> ...
SOAP 1.2, Section 5 , defines a structure for composing messages, the "SOAP Envelope". The Profile mandates the use of that structure, and places the following constraints on its use:
R9980 An ENVELOPE MUST conform to the structure specified in SOAP Version 1.2 Part 1, Section 5, "SOAP Envelope" (subject to amendment by the Profile). CORE TESTABLE BP1600
Test Assertion: | BP1600 |
---|---|
Description: | The envelope conforms to the structure specified in SOAP 1.2 Part 1, Section 5. |
Target: |
|
co-Target: metadata |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The envelope does not conform to the structure specified in SOAP 1.2 Part 1, Section 5 |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R9981 An ENVELOPE MUST have exactly zero or one
child elements of the soap12:Body
element.
CORE TESTABLE BP1881
Test Assertion: | BP1881 |
---|---|
Description: | The envelope must have exactly zero or one child elements of the soap12:Body |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The envelope does not have exactly zero or one child elements of the soap12:Body |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
While the combination of R2201 and R2210 (below) clearly imply
that there may be at most one child element of the
soap12:Body
, there is no explicit requirement in the
Profile that articulates this constraint, leading to some
confusion.
The use of unqualified element names may cause naming conflicts,
therefore qualified names must be used for the children of
soap12:Body
.
R1014 The children of the
soap12:Body
element in an ENVELOPE MUST be namespace qualified.
CORE TESTABLE BP1202
Test Assertion: | BP1202 |
---|---|
Description: | Each child element (if any) of the soap12:Body element is namespace qualified (not the grandchildren). |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A child element of the soap12:Body element is not namespace qualified. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
XML DTDs and PIs may introduce security vulnerabilities, processing overhead and semantic ambiguity when used in envelopes. As a result, certain XML constructs are disallowed by section 5 of SOAP 1.2.
Although published errata NE05 (see http://www.w3.org/XML/xml-names-19990114-errata ) allows the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace" to appear, some older processors considered such a declaration to be an error. These requirements ensure that conformant artifacts have the broadest interoperability possible.
R1008 An ENVELOPE MUST NOT contain a Document Type Declaration. CORE TESTABLE BP1007
Test Assertion: | BP1007 |
---|---|
Description: | DTDs relating to soap12:Header or soap12:Body documents, are not present in the envelope: no DOCTYPE element is present. |
Target: |
|
co-Target: metadata |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The soap12:Header or soap12:Body elements in the envelope, were described with an included DTD. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1009 An ENVELOPE MUST NOT contain Processing Instructions. CORE TESTABLE BP1208
Test Assertion: | BP1208 |
---|---|
Description: | The SOAP envelope does not include XML processing instructions. |
Target: |
|
co-Target: metadata |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | a SOAP envelope contains XML processing instructions. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1033 An ENVELOPE SHOULD NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". CORE TESTABLE BP1033
Test Assertion: | BP1033 |
---|---|
Description: | The SOAP envelope does not contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | The SOAP envelope contains the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
In many cases, senders and receivers will share some form of type information related to the envelopes being exchanged.
R1017 A RECEIVER MUST NOT mandate the use of the
xsi:type
attribute in envelopes except as required in
order to indicate a derived type (see XML Schema Part 1:
Structures, Section 2.6.1). CORE
NOT_TESTABLE
R1032 The soap12:Envelope
,
soap12:Header
, and soap12:Body
elements
in an ENVELOPE MUST NOT have
attributes in the namespace
"http://www.w3.org/2003/05/soap-envelope"
.
CORE TESTABLE BP1032
Test Assertion: | BP1032 |
---|---|
Description: | The soap12:Envelope, soap12:Header, and soap12:Body elements do not have any attributes in the namespace "http://schemas.xmlsoap.org/soap/envelope/" |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A soap12:Envelope, soap12:Header, or soap12:Body element has an attribute in the namespace "http://schemas.xmlsoap.org/soap/envelope/". |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
SOAP 1.2, Section 2 defines a model for the processing of envelopes. In particular, it defines rules for the processing of header blocks and the envelope body. It also defines rules related to generation of faults. The Profile places the following constraints on the processing model:
When a fault is generated, no further processing should be performed. In request-response exchanges, a fault message will be transmitted to the sender of the request, and some application level error will be flagged to the user.
Both SOAP and this Profile use the term 'generate' to denote the creation of a SOAP Fault. It is important to realize that generation of a Fault is distinct from its transmission, which in some cases is not required.
R1029 Where the normal outcome of processing a SOAP envelope would have resulted in the transmission of a SOAP response, but rather a fault is generated instead, the RECEIVER MUST NOT transmit the non-faulting response. CORE NOT_TESTABLE
Note that there may be valid reasons (such as security considerations) why a fault might not be transmitted.
Some consumer implementations erroneously use only the HTTP
status code to determine the presence of a Fault. Because there are
situations where the Web infrastructure changes the HTTP status
code, and for general reliability, the Profile requires that they
examine the envelope. A Fault is an envelope that has a single
child element of the soap12:Body
element, that element
being the soap12:Fault
element.
R1107 A RECEIVER MUST interpret a SOAP message as
a Fault when the soap12:Body
of the message has a
single soap12:Fault
child. CORE NOT_TESTABLE
While SOAP itself is not transport specific, this Profile focuses on its use with HTTP and makes no requirements on the use of any other transport. Other profiles might be developed to focus on the particulars of other transports, but that is out of scope for this Profile. With respect to compliance to this Profile, any requirement that mentions the HTTP transport applies only when HTTP is being used. Any requirement that is not specific to HTTP (i.e. does not mention HTTP specifically) applies toward conformance regardless of the transport mechanism being used.
Section 7 of SOAP 1.2 Part 2 defines a single protocol binding, for HTTP/1.1 . The Profile makes use of that binding, and places the following constraints on its use:
For this section, the conformance criteria for the use of HTTP as a transport protocol are specified in Section 2.3 .
Several versions of HTTP are defined. HTTP/1.1 has performance advantages, and is more clearly specified than HTTP/1.0.
R1141 When HTTP is used as the transport, a MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0. HTTP-TRANSPORT TESTABLE BP1002
Test Assertion: | BP1002 |
---|---|
Description: | If it is a request, the arg #2 of POST is <HTTP/1.1> or <HTTP/1.0>. If absent, first line of the body is: HTTP-Version = HTTP/1.1. (or HTTP/1.0). If it is a response, it starts with <HTTP/1.1> or <HTTP/1.0> |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The message that is sent over HTTP, is not sent using HTTP/1.1 or HTTP/1.0. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1140 When HTTP is used as the transport, a MESSAGE SHOULD be sent using HTTP/1.1. HTTP-TRANSPORT TESTABLE BP1001
Test Assertion: | BP1001 |
---|---|
Description: | If it is a request, the arg #2 of POST is <HTTP/1.1>. If absent, first line of the body is: HTTP-Version = HTTP/1.1. If it is a response, it starts with <HTTP/1.1> |
Target: |
|
Prerequisite: | BP1002 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | The message is not sent using HTTP/1.1. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Note that support for HTTP/1.0 is implied in HTTP/1.1, and that intermediaries may change the version of a message; for more information about HTTP versioning, see RFC2145, "Use and Interpretation of HTTP Version Numbers."
Testing has demonstrated that requiring parameters on the
Content-Type
MIME header field-value to be quoted
increases interoperability of implementations. Even though HTTP
allows unquoted header field-values, some SOAP implementations
require that they be quoted.
R1109 If present, the values of the following
parameters - type
, start-info
,
action
, and boundary
- on the
Content-Type
MIME header field-value in a request
MESSAGE MUST be a quoted
string. HTTP-TRANSPORT TESTABLE BP1006
Test Assertion: | BP1006 |
---|---|
Description: | The action header contains a quoted string of any value, including "". |
Target: |
|
Prerequisite: | BP1761 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | action HTTP header does not contain a quoted string. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1119 A RECEIVER MAY respond with a fault if the
applicable parameters on the Content-Type
MIME header
field-value in a message are not quoted. HTTP-TRANSPORT NOT_TESTED
R1127 A RECEIVER MUST NOT rely on the value of
the action
parameter on the Content-Type
MIME header field-value to correctly process the message.
HTTP-TRANSPORT NOT_TESTABLE
HTTP uses the 2xx series of status codes to communicate success. In particular, 200 is the default for successful messages, but 202 can be used to indicate that a message has been submitted for processing. Additionally, other 2xx status codes may be appropriate, depending on the nature of the HTTP interaction.
R1124 An INSTANCE MUST use a 2xx HTTP status code on a response message that indicates the successful outcome of a HTTP Request. HTTP-TRANSPORT NOT_TESTABLE
R1111 An INSTANCE SHOULD use a "200 OK" HTTP status code on a response message that contains an envelope that is not a fault. HTTP-TRANSPORT TESTABLE BP1100
Test Assertion: | BP1100 |
---|---|
Description: | The message uses a "200 OK" HTTP status code. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | The envelope of the response message does not contain a soap12:Fault and the message does not use a "200 OK" HTTP status code. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1112 An INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP status code for a response message that does not contain a SOAP envelope but indicates the successful outcome of a HTTP Request. HTTP-TRANSPORT TESTABLE BP1101
Test Assertion: | BP1101 |
---|---|
Description: | The response message, if successfully processed at HTTP level, is sent using either a "200 OK" or "202 Accepted" HTTP status code. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | A response message without a SOAP message, is not using either a "200 OK" or "202 Accepted" HTTP status code, though successful at HTTP level. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Despite the fact that the HTTP 1.1 assigns different meanings to response status codes "200" and "202", in the context of the Profile they should be considered equivalent by the initiator of the request. The Profile accepts both status codes because some SOAP implementations have little control over the HTTP protocol implementation and cannot control which of these response status codes is sent.
There are interoperability problems with using many of the HTTP redirect status codes, generally surrounding whether to use the original method, or GET. The Profile mandates "307 Temporary Redirect", which has the semantic of redirection with the same HTTP method, as the correct status code for redirection. For more information, see the 3xx status code descriptions in RFC2616.
R1130 An INSTANCE MUST use the "307 Temporary Redirect" HTTP status code when redirecting a request to a different endpoint. HTTP-TRANSPORT NOT_TESTABLE
R1131 A CONSUMER MAY automatically redirect a request when it encounters a "307 Temporary Redirect" HTTP status code in a response. HTTP-TRANSPORT NOT_TESTED
RFC2616 notes that user-agents should not automatically redirect requests; however, this requirement was aimed at browsers, not automated processes (which many Web services will be). Therefore, the Profile allows, but does not require, consumers to automatically follow redirections.
The HTTP State Management Mechanism ("Cookies") allows the creation of stateful sessions between Web browsers and servers. Being designed for hypertext browsing, Cookies do not have well-defined semantics for Web services, and, because they are external to the envelope, are not accommodated by either SOAP 1.2 or WSDL 1.1. However, there are situations where it may be necessary to use Cookies; e.g., for load balancing between servers, or for integration with legacy systems that use Cookies. For these reasons, the Profile limits the ways in which Cookies can be used, without completely disallowing them.
R1120 An INSTANCE MAY use the HTTP state mechanism ("Cookies"). HTTP-TRANSPORT NOT_TESTED
R1122 An INSTANCE using Cookies SHOULD conform to RFC2965. HTTP-TRANSPORT NOT_TESTED
R1121 An INSTANCE SHOULD NOT require consumer support for Cookies in order to function correctly. HTTP-TRANSPORT NOT_TESTED
R1123 The value of the cookie MUST be considered to be opaque by the CONSUMER. HTTP-TRANSPORT NOT_TESTABLE
The Profile recommends that cookies not be required by instances for proper operation; they should be a hint, to be used for optimization, without materially affecting the execution of the Web service. However, they may be required in legacy integration and other exceptional use cases, so requiring them does not make an instance non-conformant. While Cookies thus may have meaning to the instance, they should not be used as an out-of-bound data channel between the instance and the consumer. Therefore, interpretation of Cookies is not allowed at all by the consumer - it is required to treat them as opaque (i.e., have no meaning to the consumer).
Definition: non-addressable
A CONSUMER or INSTANCE is deemed "non-addressable" when, for whatever reason, it is either unwilling or unable to provide a network endpoint that is capable of accepting connections. This means that the CONSUMER or INSTANCE cannot service incoming HTTP connections and can only transmit HTTP Request messages and receive HTTP Response messages.
Non-addressable CONSUMERs and INSTANCEs, by their nature, cannot service incoming HTTP connections. Therefore any ENVELOPEs that they receive, either as requests (in the case of INSTANCEs) or responses (in the case of CONSUMERs), MUST, when HTTP is used, be carried in the entity-body of an HTTP Request message.
R1201 When a CONSUMER is non-addressable, a SOAP ENVELOPE, that is described by the input message of a WSDL operation supported by an INSTANCE, MUST be bound to a HTTP Request message. HTTP-TRANSPORT TESTABLE BP1125a BP1125b
Test Assertion: | BP1125a |
---|---|
Description: | When a CONSUMER is non-addressable, a SOAP ENVELOPE, that is described by the input message of a WSDL doc-lit operation supported by an INSTANCE, MUST be bound to a HTTP Request message. |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope for a WSDL doc/lit bound request message, with a wsa:ReplyTo anonymous, was sent over an HTTP response. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1125b |
---|---|
Description: | When a CONSUMER is non-addressable, a SOAP ENVELOPE, that is described by the input message of a WSDL rpc-lit operation supported by an INSTANCE, MUST be bound to a HTTP Request message. |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope for a WSDL rpc/lit bound request message, with a wsa:ReplyTo anonymous, was sent over an HTTP response. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1202 When a CONSUMER is non-addressable, a SOAP ENVELOPE, that is described by the output message of a WSDL operation supported by an INSTANCE, MUST be bound to a HTTP Response message. HTTP-TRANSPORT TESTABLE BP1126a BP1126b
Test Assertion: | BP1126a |
---|---|
Description: | When a CONSUMER is non-addressable, a SOAP ENVELOPE, that is described by the output message of a WSDL doc-lit operation supported by an INSTANCE, MUST be bound to a HTTP Response message. |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope for a WSDL doc/lit bound response message, related to a request containing a wsa:ReplyTo anonymous, was sent over an HTTP request. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1126b |
---|---|
Description: | When a CONSUMER is non-addressable, a SOAP ENVELOPE, that is described by the output message of a WSDL rpc-lit operation supported by an INSTANCE, MUST be bound to a HTTP Response message. |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope for a WSDL rpc/lit bound response message, related to a request containing a wsa:ReplyTo anonymous, was sent over an HTTP request. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1203 When an INSTANCE is non-addressable, a SOAP ENVELOPE, that is described by the input message of a WSDL operation supported by the INSTANCE, MUST be bound to a HTTP Response message. HTTP-TRANSPORT TESTABLE
R1204 When an INSTANCE is non-addressable, a SOAP ENVELOPE, that is described by the output message of a WSDL operation supported by the INSTANCE, MUST be bound to a HTTP Request message. HTTP-TRANSPORT TESTABLE
Note that INSTANCEs can poll for requests from CONSUMERs using mechanisms such as those described in WS-MakeConnection .
This section of the Profile incorporates the following specifications by reference:
SOAP 1.2, Section 6 describes the use URIs as
identifiers. For example, the role
attribute value is
a URI that identifies the SOAP node(s) to which a particular header
block is targeted. To ensure interoperability it is important that
SENDERs and RECEIVERs share a common understanding of how such URI
values will be compared. The Profile places the following
constraints on the use of such URI values:
A SOAP 1.2 defined URI, such as the role
value
"http://www.w3.org/2003/05/soap-envelope/role/next", is treated as
follows:
R1160 A RECEIVER, for the purposes of comparison of URI values of information items defined by the SOAP 1.2 specification, MUST treat the computed absolute URI values as simple strings as defined in RFC3986 (see RFC3986, Section 6.2.1). CORE NOT_TESTABLE
This section of the Profile incorporates the following specifications by reference:
WS-Addressing is a part of core Web services infrastructure. To facilitate interoperability and to provide a common baseline, this profile requires compliant clients and services to provide support for WS-Addressing Core, WS-Addressing SOAP Binding and WS-Addressing Metadata, as modified by this Profile.
Support for WS-Addressing by a specific "service" is optional. However, a service may require the use of WS-Addressing, in which case, for successful interaction with that service, a client will need to support it.
Note that two BP compliant web services instances may both
support the use of WS- Addressing yet fail to agree on a common set
of features necessary to interact with one another. For example, a
RECEIVER may require the use of non-anonymous response EPRs (and
advertise this via the wsam:NonAnonymousResponses
nested policy assertion) yet a SENDER, for various reasons (e.g.
the presence of NATs or firewalls), may only support the use of
anonymous response EPRs.
R1040 If an endpoint requires use of
WS-Addressing by use of a wsam:Addressing
policy
assertion, an ENVELOPE sent
by a SENDER MUST carry all required WS-Addressing SOAP headers.
CORE NOT_TESTED
R1041 An ENVELOPE that is a MustUnderstand SOAP fault, sent from an endpoint that has a policy alternative containing the wsam:Addressing assertion attached to its WSDL endpoint subject, MUST NOT contain a NotUnderstood SOAP header block with the qname attribute value that identifies a WS-Addressing defined SOAP header block. CORE NOT_TESTED
WS-Addressing 1.0 - Metadata, Section 5.1 defines additional constraints on the cardinality of WS-Adressing Message Addressing Properties defined in WS-Addressing 1.0 - Core. These constraints are defined for every message involved in WSDL 1.1 transmission primitives. The Profile requires conformance to this section when WS-Addressing is used in conjunction with a WSDL 1.1 description.
R1142 An ENVELOPE that includes a
wsa:Action
SOAP header block and which is described
using a WSDL 1.1 description MUST conform to WS-Addressing 1.0 -
Metadata, Section 5.1. CORE
TESTABLE BP1142a BP1142b BP1142c BP1143a BP1143b BP1143c
Test Assertion: | BP1142a |
---|---|
Description: | The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. For a request message, with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - If there is an EPR attached to the corresponding wsdl:port definition, then the wsa:To element must be present - the wsa:RelatesTo/@RelationshipType must be present with value "http://www.w3.org/2005/08/addressing/reply" (this is covered by 2nd cotarget presence) - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl - If the operation binding includes a wsdl:output element then there must be wsa:messageID and a wsa:ReplyTo elements present in the soap12:Header |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
( /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:service/ wsdl:port[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@binding), . )) = $myOpBinding/../@name ]/wsa:EndpointReference ) then (some $portEpr in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:service/ wsdl:port[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@binding), . )) = $myOpBinding/../@name ]/wsa:EndpointReference satisfies ( $target/soap12:Header/wsa:To ) ) else fn:true() ) and ( if ( $myOpBinding/wsdl:output ) then ($target/soap12:Header/wsa:MessageID) else fn:true() ) and (: correct wsa:Action value :) (some $opmsg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/ wsdl:operation[ $myOpBinding/@name = @name ]/wsdl:input satisfies ($target/soap12:Header/wsa:Action = ( if ($opmsg/@wsam:Action) then $opmsg/@wsam:Action else fn:string-join(($opmsg/../../../@targetNamespace,$opmsg/../../@name, if($opmsg/@name) then $opmsg/@name else fn:string-join(($opmsg/../@name, 'Request' ),'' ) ),'/' ) ) ) ) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a request message, with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - If there is an EPR attached to the corresponding wsdl:port definition, then the wsa:To element must be present - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl - If the operation binding includes a wsdl:output element then there must be wsa:messageID and a wsa:ReplyTo elements present in the soap12:Header |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1142b |
---|---|
Description: | The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. http://www.w3.org/2005/08/addressing/reply IRI. For a response message with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have the anonymous address - the wsa:To element, if present, must have the anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl |
Target: |
|
co-Target: myOpBinding |
|
co-Target: related-Request |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a response message with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have the anonymous address - the wsa:To element, if present, must have the anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1142c |
---|---|
Description: | The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. http://www.w3.org/2005/08/addressing/reply IRI. For a non-anonymous response message with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have a non-anonymous address - the wsa:To element must be present, and must have a non-anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl |
Target: |
|
co-Target: myOpBinding |
|
co-Target: related-Request |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a non-anonymous response message with a wsa:Action element, defined using an rpc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have a non-anonymous address - the wsa:To element must be present, and must have a non-anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1143a |
---|---|
Description: | The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. For a request message, with a wsa:Action element, defined using a doc/lit binding, the following must hold: - If there is an EPR attached to the corresponding wsdl:port definition, then the wsa:To element must be present - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence) - If the operation binding includes a wsdl:output element then there must be wsa:messageID and a wsa:ReplyTo present in the soap12:Header |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a request message, with a wsa:Action element, defined using a doc/lit binding, the following must hold: - If there is an EPR attached to the corresponding wsdl:port definition, then the wsa:To element must be present - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence) - If the operation binding includes a wsdl:output element then there must be wsa:messageID and a wsa:ReplyTo elements present in the soap12:Header |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1143b |
---|---|
Description: | The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. http://www.w3.org/2005/08/addressing/reply IRI. For a response message with a wsa:Action element, defined using a doc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have the anonymous address - the wsa:RelatesTo/@RelationshipType must be present with value "http://www.w3.org/2005/08/addressing/reply" (this is covered by 2nd cotarget presence) - the wsa:To element, if present, must have the anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence) |
Target: |
|
co-Target: myOpBinding |
|
co-Target: related-Request |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a response message with a wsa:Action element, defined using a doc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have the anonymous address - the wsa:To element, if present, must have the anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1143c |
---|---|
Description: | The envelope must conform to WS-Addressing WSDL Binding, Section 5.1. http://www.w3.org/2005/08/addressing/reply IRI. For a non anon response message with a wsa:Action element, defined using a doc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have a non-anonymous address - the wsa:RelatesTo/@RelationshipType must be present with value "http://www.w3.org/2005/08/addressing/reply" (this is covered by 2nd cotarget presence) - the wsa:To element, must be present and not anonymous - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence) |
Target: |
|
co-Target: myOpBinding |
|
co-Target: related-Request |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope does not conform to WS-Addressing WSDL Binding, Section 5.1. For a non anon response message with a wsa:Action element, defined using a doc/lit binding, the following must hold: - the wsa:ReplyTo EPR in the related Request message must have a non-anonymous address - the wsa:To element, must be present with a non-anonymous value - The wsa:Action value in the soap12:Header must equal to that specified from the wsdl (this is covered by the cotarget presence) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
There could be some confusion with regards to the range of valid
values for the action
parameter on the
Content-Type
MIME header when WS-Addressing is
used.
When composed with WS-Addressing, the value of the
action
parameter, if present, is limited to the
absolute URI that matches the value specified for
wsa:Action
. The action
parameter is
optional and is therefore not required to be present on the header.
This is useful, for example, when the value of
wsa:Action
is sensitive and is therefore
encrypted.
R1144 When the wsa:Action
MAP is
present in an envelope, the value of the action
parameter, if present, on the Content-Type
MIME header
of the MESSAGE MUST be an
absolute URI that has the same value as the value of the
wsa:Action
MAP. CORE
TESTABLE BP1144
Test Assertion: | BP1144 |
---|---|
Description: | The message must specify an action HTTP header with either a value that is an absolute URI that has the same value as the value of the wsa:Action MAP, or a value of "" (empty string). |
Target: |
|
Prerequisite: | BP1761 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A message did not specify an action HTTP header with either a value that is an absolute URI that has the same value as the value of the wsa:Action MAP, or a value of "" (empty string). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
WS-Addressing provides the URI
http://www.w3.org/2005/08/addressing/soap/fault
for
"SOAP defined faults". However, it only recommends, rather than
mandates its use for the SOAP 1.2 defined MustUnderstand and
VersionMismatch faults. This Profile mandates the use of the
WS-Addressing defined wsa:Action value for SOAP 1.2 defined
MustUnderstand and VersionMismatch faults, for
interoperability.
R1035 An ENVELOPE MUST use the
http://www.w3.org/2005/08/addressing/soap/fault URI as the value
for the wsa:Action
element, when present, for either
of the SOAP 1.2 defined VersionMismatch and MustUnderstand faults.
CORE TESTABLE BP1035
Test Assertion: | BP1035 |
---|---|
Description: | The value of the wsa:Action element is http://www.w3.org/2005/08/addressing/soap/fault |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A fault response does not contain the expected wsa:Action value of http://www.w3.org/2005/08/addressing/soap/fault. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
WS-Addressing 1.0 - SOAP Binding defines multiple SOAP header blocks (wsa:To, wsa:From, wsa:ReplyTo, wsa:FaultTo, wsa:Action, wsa:MessageID, and wsa:RelatesTo). These SOAP header blocks are part of the same module. A SOAP node that conforms to the Profile understands and honors all of these SOAP header blocks (when it understands WS-Addressing) or none at all (when it does not understand WS-Addressing).
R1143 When a message contains multiple
WS-Addressing SOAP header blocks with at least one of those header
blocks containing a soap12:mustUnderstand='1'
attribute, then a RECEIVER MUST honor all the WS-Addressing SOAP
header blocks or none of them. CORE
NOT_TESTABLE
When WS-Addressing MAPs are present in a SOAP envelope, but do
not contain a soap12:mustUnderstand="1"
attribute, a
RECEIVER may choose to ignore these SOAP headers (per R1143 ). Consistent with R1036 , valid reasons may exist why (not where)
faults are not transmitted.
R1145 If a SOAP envelope does not contain any
WS-Addressing MAPs, or contains WS-Addressing MAPs that do not
include any soap12:mustUnderstand="1"
attributes and
the RECEIVER chooses to
ignore them, then any response (normal or fault) SHOULD be
transmitted. If it is transmitted then it is transmitted on the
HTTP Response message (if available). HTTP-TRANSPORT NOT_TESTED
When any WS-Addressing MAPs are present in a SOAP envelope
(where soap12:mustUnderstand="1"
attributes exist or
the header contents are understood), any non-faulting response will
be transmitted to the [reply endpoint] MAP. Should a fault be
generated, it replaces the non-faulting response.
R1146 A RECEIVER MUST transmit non-faulting responses to the endpoint referred to by the value of the [reply endpoint] MAP or generate a fault instead (per R1029). CORE TESTABLE BP1146
Test Assertion: | BP1146 |
---|---|
Description: | A non-faulting response must be sent to the [reply endpoint] MAP or generate a fault instead. |
Target: |
|
co-Target: myRequestMsg |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A response message was sent to a destination other than the expected [reply endpoint] MAP, i.e. different from wsa:ReplyTo in the request message. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
SOAP 1.2 allows a RECEIVER to ignore headers that it does not understand. This behavior is particularly relevant for WS-Addressing headers that affect message processing and routing. As an example, take the following message sent to a SOAP node that does not understand the "http://www.w3.org/2005/08/addressing" namespace:
<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing"> <soap12:Header> <wsa:MessageID>uuid:8B82EA41-1485-13A6-5631527DC83F4168</wsa:MessageID> <wsa:Action>http://www.wstf.org/docs/scenarios/sc002/Echo</wsa:Action> <wsa:ReplyTo> <wsa:Address>http://server.foobie.com/NotifyEcho/asynchResp</wsa:Address> </wsa:ReplyTo> . . . </soap12:Header> <soap12:Body> . . . </soap12:Body> </soap12:Envelope>
The SENDER expects the response to be sent "server.foobie.com". Yet, because it does not recognize the WS-Addressing 1.0 namespace, the RECEIVER will ignore the WS-Addressing headers as if WS-Addressing weren't engaged; consequently the SOAP response will be sent in the entity-body of the HTTP Response and may be missed by the SENDER.
Another example is where a message with an empty SOAP Body
carries the semantic intent in its wsa:Action
header.
In situations where the ability of the receiving node to
understand WS-Addressing 1.0 headers is in doubt and the correct
processing of the WS-Addressing is semantically significant (such
as the two examples given), the SENDER is encouraged to add the
soap12:mustUnderstand
attribute with a value of "1" to
the wsa:Action
header. This prompts the RECEIVER to
generate a MustUnderstand fault in cases where the WS-Addressing
headers are not understood.
SOAP MustUnderstand and VersionMismatch faults are detected irrespective of the use of WS-Addressing MAPs. There may be valid reasons why (not where) faults are transmitted, e.g. security concerns or the HTTP Response connection is no longer available. In these cases the SENDER will not receive any SOAP envelope response.
R1036 Regardless of whether the
wsa:ReplyTo
or wsa:FaultTo
SOAP headers
appear in the incoming message, a RECEIVER that receives a SOAP envelope
that generates either a SOAP MustUnderstand or VersionMismatch
fault SHOULD transmit either fault. If it is transmitted, such a
fault is transmitted on the HTTP Response message (if available).
HTTP-TRANSPORT NOT_TESTED
When WS-Addressing MAPs are present in a SOAP envelope (where
soap12:mustUnderstand="1"
attributes exist or the
header contents are understood), should a fault be generated, it
will be transmitted to the [fault endpoint] MAP. WS-Addressing
specifies expected behavior should the [fault endpoint] be
absent.
R1147 If a fault is generated, the RECEIVER SHOULD transmit the fault (per R1029). CORE NOT_TESTED
R1161 Other than those faults specified in R1036, faults in R1147 SHOULD be transmitted by the RECEIVER as specified in WS-Addressing 1.0 - Core, Section 3.4. CORE TESTABLE
R1162 When the [fault endpoint] MAP exists, the RECEIVER MUST NOT transmit faults to the endpoint referred to by the value of the [reply endpoint] MAP. CORE TESTABLE
R1148 If an error occurs when transmitting the fault in R1147, a RECEIVER MAY choose to send a fault related to this transmission error on the HTTP Response (if available). HTTP-TRANSPORT NOT_TESTED
Note: To avoid a recursive situation, if a fault is generated while trying to use the [reply endpoint] MAP (R1146 ) and the [fault endpoint] MAP is absent, R1147 does not apply.
When sending a one-way message the SENDER could choose to ignore any possible response - for example, a fault. However, if the SENDER is interested in receiving those messages, the SENDER will need to include a [message id] property in the one-way message to ensure that the response can be successfully transmitted (see WS-Addressing 1.0 - Core, Section 3.4 ).
R1163 When applying the processing rules defined
by WS-Addressing 1.0 - Core, Section 3.4, if a
related message lacks a [message id] property, the RECEIVER MUST generate a
wsa:MessageAddressingHeaderRequired
fault.
CORE TESTABLE
While the RECEIVER is under no obligation to transmit faults, including a [message id] property will provide the RECEIVER with sufficient information to generate a response if needed.
There may be many reasons (e.g. security, unsupported wsa:Address values, ...) why a RECEIVER does not honor any WS-Addressing MAPs. In these cases and irrespective of where the condition occurs, when any WS-Addressing MAPs are present in a SOAP envelope (where soap12:mustUnderstand=1 attributes exist or the header contents are understood), the RECEIVER must generate a fault.
R1149 If any WS-Addressing MAPs are not honored, the RECEIVER MUST generate a fault. CORE NOT_TESTABLE
The WS-Addressing [destination] URI of an outgoing message influences where this message will be sent. In the case of the outgoing response (normal or fault), if this URI is a non-anonymous URI then this message will be sent over a separate HTTP connection from one used to carry the request message.
R1152 If an INSTANCE attempts to send a message to a non-anonymous [destination] URI then the message MUST be transmitted in the entity-body of an HTTP Request. CORE TESTABLE BP1152a BP1152b BP1152c
Test Assertion: | BP1152a |
---|---|
Description: | The message must be sent in the entity body of an HTTP request in a separate HTTP connection specified by the response EPR using the SOAP 1.1 Request Optional Response HTTP binding. |
Target: |
|
co-Target: myRequestMsg |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A response message was not sent in the entity body of an HTTP request in a separate HTTP connection as required by the (non-anonymous) response EPR. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1152b |
---|---|
Description: | The message must be sent in the entity body of an HTTP request in a separate HTTP connection specified by the response EPR using the SOAP 1.1 Request Optional Response HTTP binding. |
Target: |
|
co-Target: myRequestMsg |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A response message was not sent in the entity body of an HTTP request in a separate HTTP connection as required by the (non-anonymous) response EPR. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1152c |
---|---|
Description: | The message must be sent in the entity body of an HTTP request in a separate HTTP connection specified by the response EPR using the SOAP 1.1 Request Optional Response HTTP binding. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A message with a non-anonymous destination was not sent in the entity body of an HTTP request in a separate HTTP connection as required by the (non-anonymous) destination EPR. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
WS-Addressing 1.0 - Core and WS-Addressing 1.0 - Metadata are
unclear about whether and when the wsa:To
header
element is required in a SOAP message. This Profile makes the
following, clarifying requirement.
R1153 Except in cases in which a RECEIVER exposes a WSDL description and
its endpoint includes a wsdl:port
that has been
extended with a wsa:EndpointReference
, a RECEIVER MUST NOT fault a SOAP request
message due to the absence of the wsa:To
header.
CORE TESTABLE BP1153a BP1153b
Test Assertion: | BP1153a |
---|---|
Description: | For a request message, defined using a doc/lit binding, the following must hold: - If there is no EPR attached to the corresponding wsdl:port definition, then in case there is no wsa:To element, the message should not be faulted. |
Target: |
|
co-Target: myOpBinding |
|
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope for a doc/lit bound request message, without wsa:To in a message bound to a port that is NOT extended with wsa:EndpointReference has generated a Fault in response. Verify that this fault is not caused by the absence of wsa:To. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1153b |
---|---|
Description: | For a request message, defined using a rpc/lit binding, the following must hold: - If there is no EPR attached to the corresponding wsdl:port definition, then in case there is no wsa:To element, the message should not be faulted. |
Target: |
|
co-Target: myOpBinding |
|
Prerequisite: |
|
Predicate: |
( /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:service/ wsdl:port[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@binding), . )) = $myOpBinding/../@name and not(wsa:EndpointReference)] ) then ( not (/wsil:testLog/wsil:messageLog/wsil:message[(@type = 'response' and @conversation = $target/../../@conversation) or (.//soap12:Envelope/soap12:Header/wsa:RelatesTo = $target/soap12:Header/wsa:MessageID)] /wsil:messageContents/soap12:Envelope/soap12:Body/soap12:Fault ) ) else fn:true() ) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An envelope for a rpc/lit bound request message, without wsa:To in a message bound to a port that is NOT extended with wsa:EndpointReference has generated a Fault in response. Verify that this fault is not caused by the absence of wsa:To. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Although the wsa:To
header is optional, as a matter
of best practice implementations are encouraged to include this
header (with a non-anonymous value) as its presence provides a
greater degree of flexibility in handling certain situations; for
example, when moving a service endpoint from one URI to
another.
As per WS-Addressing 1.0 - Core, the [destination] message
addressing property of a request message without a
wsa:To
header is
"http://www.w3.org/2005/08/addressing/anonymous". Note that none of
the WS-Addressing 1.0 specifications describes the semantics of
sending a SOAP request message, over HTTP, either without a
wsa:To
header or with a wsa:To
header
with the value of "http://www.w3.org/2005/08/addressing/anonymous".
To clarify, such a request is considered to be addressed to "the
entity listening at the URI of the HTTP Request that contains this
message". Sent over a connection to http://www.example.org, the
following three example messages are consistent:
For example,
CORRECT:
POST /NotifyEcho/soap12service HTTP/1.1 Content-Type: text/xml;charset=UTF-8 ... <soap12:Envelope ...> <soap12:Header> <wsa:Action>http://www.wstf.org/sc002/Echo</wsa:Action> </soap12:Header> <soap12:Body> ... </soap12:Body> </soap12:Envelope>
CORRECT:
POST /NotifyEcho/soap12service HTTP/1.1 Content-Type: text/xml;charset=UTF-8 ... <soap12:Envelope ...> <soap12:Header> <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To> <wsa:Action>http://www.wstf.org/sc002/Echo</wsa:Action> </soap12:Header> <soap12:Body> ... </soap12:Body> </soap12:Envelope>
CORRECT:
POST /NotifyEcho/soap12service HTTP/1.1 Content-Type: text/xml;charset=UTF-8 ... <soap12:Envelope ...> <soap12:Header> <wsa:To>http://www.example.org/NotifyEcho/soap12service</wsa:To> <wsa:Action>http://www.wstf.org/sc002/Echo</wsa:Action> </soap12:Header> <soap12:Body> ... </soap12:Body> </soap12:Envelope>
WS-Addressing 1.0 - Metadata is unclear about the relationship
between the elements of a WSDL 1.1 description of an endpoint and
the values of the addressing properties of a message sent to that
endpoint. In particular, the value of the [destination] message
addressing property needs to be clarified in order to insure
interoperability between SENDER and RECEIVER. There are two cases
to consider. The first case is where the wsdl:port
has
been extended with a wsa:EndpointReference
as
described by Section 4.1 of WS-Addressing 1.0 - Metadata. In this
case the following requirement applies:
R1154 When sending a request message to an
endpoint which is specified by a WSDL 1.1 description in which the
wsdl:port
element has been extended with a
wsa:EndpointReference
, if WS-Addressing is engaged the
SENDER MUST populate the
[destination] and [reference parameters] properties of that request
message with the values of the [address] and [reference parameters]
properties (respectively) of the extending endpoint reference.
CORE TESTABLE
Note that, since [address] is a required property of an endpoint
reference, extending a wsdl:port
with a
wsa:EndpointReference
has the effect of populating the
[destination] property of the outgoing message, thus mandating the
inclusion of the wsa:To
header.
The second case is where the wsdl:port
has not been
extended with a wsa:EndpointReference
.
R1155 When sending a request message to an
endpoint which is specified by a WSDL 1.1 description in which the
wsdl:port
element has not been
extended with a wsa:EndpointReference
, if
WS-Addressing is engaged the SENDER MAY populate the [destination]
message address property of the request message with the value of
the location
attribute of the
wsoap12:address
extension element. CORE TESTABLE
WS-Addressing 1.0 - Metadata defines a policy assertion,
wsam:Addressing
, that is used to indicate whether
WS-Addressing is supported or required. It is a nested policy
container assertion and can contain additional restrictions
(specifically the wsam:AnonymousResponses
and
wsam:NonAnonymousResponses
policy assertions) on the
value of the response endpoint EPRs in request messages. A
top-level assertion without any nested assertions implies that both
anonymous and non-anonymous are allowed. The WS-Addressing 1.0 -
Metadata specification sets the scope of this assertion to be
endpoint policy subject. However, with regards to the
anonymous/non-anonymous restrictions, experience has shown that it
is often desirable to have different policies for different
operations on the same endpoint. For example, some of the
operations of an endpoint may need to be synchronous while others
may need to be asynchronous. It is worthwhile to indicate this
difference in a WSDL description. In the absence of any guidance on
the mechanism(s) for expressing such per-operation distinctions,
individual implementations will create their own extensions for
enabling this feature. To avoid the interoperability problems
inherent in such an approach, the Profile defines the following
extension to the behavior defined by WS-Addressing 1.0
Metadata.
WS-Addressing 1.0 Metadata allows policies containing the
wsam:Addressing
policy assertion to be attached to
either a wsdl:port
or a wsdl:binding
. To
these two options the Profile adds a third option which allows
policies containing the wsam:Addressing
policy
assertion to be attached to
wsdl:binding/wsdl:operation
elements. When the
wsam:Addressing
policy assertion is attached to the
wsdl:binding/wsdl:operation
element, it applies to the
operation policy subject. Nevertheless, it should always be the
case that if one operation of an endpoint supports or requires
WS-Addressing, then all operations of that endpoint must support or
require WS-Addressing (although, potentially, with different
restrictions). Furthermore, to simplify the calculation of the
effective policy for each operation and decrease the possibility of
creating conflicting policies, each operation within such an
endpoint should affirmatively declare its policy with respect to
WS-Addressing.
R1156 In a DESCRIPTION, a policy that contains the
wsam:Addressing
assertion MUST be attached to either a
wsdl:port
, a wsdl:binding
or a
wsdl:binding/wsdl:operation
. CORE NOT_TESTABLE_XPATH
R1157 If a DESCRIPTION has a policy alternative
containing the wsam:Addressing
assertion attached to a
wsdl:binding/wsdl:operation
, then all of the
wsdl:operation
s within that wsdl:binding
MUST also have a policy alternative containing the
wsam:Addressing
assertion attached to them.
CORE NOT_TESTABLE_XPATH
In addition to the above restrictions and as stated in R1158 , the effective policy alternatives for a given policy subject must not contain conflicting assertions.
For example,
INCORRECT:
<wsdl:binding name="sc009SOAP12Binding" type="tns:sc009PortType"> <wsp:Policy> <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> ... <wsdl:operation name="CreatePO"> <wsp:Policy> <wsam:Addressing> <wsp:Policy> <wsam:NonAnonymousResponses/> </wsp:Policy> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> <wsdl:operation name="GetPOStatus"> ... </wsdl:operation> <wsdl:operation name="UpdatePO"> <wsp:Policy> <wsam:Addressing> <wsp:Policy> <wsam:NonAnonymousResponses/> </wsp:Policy> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> <wsdl:operation name="CancelPO"> ... </wsdl:operation> </wsdl:binding> <wsdl:service name="sc009Service"> <wsdl:port name="soap12port" binding="tns:sc009SOAP12Binding"> ... </wsdl:port> </wsdl:service>
The above example is incorrect for two reasons. Firstly, it
violates R1157 because the GetPOStatus and CancelPO operations do
not have policies containing the wsam:Addressing
assertion attached to them. Secondly, the effective policies for
both the CreatePO and UpdatePO operations contain conflicting
assertions (a wsam:Addressing
assertion that is
unconstrained with regards to anonymous/non-anonymous and a
wsam:Addressing
assertion that is constrained to just
non-anonymous) within the same alternative.
For example,
INCORRECT:
<wsdl:binding name="sc009SOAP12Binding" type="tns:sc009PortType"> ... <wsdl:operation name="CreatePO"> <wsp:Policy> <wsam:Addressing> <wsp:Policy> <wsam:NonAnonymousResponses/> </wsp:Policy> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> <wsdl:operation name="GetPOStatus"> <wsp:Policy> <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> <wsdl:operation name="UpdatePO"> <wsp:Policy> <wsam:Addressing> <wsp:Policy> <wsam:NonAnonymousResponses/> </wsp:Policy> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> <wsdl:operation name="CancelPO"> <wsp:Policy> <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> </wsdl:binding> <wsdl:service name="sc009Service"> <wsdl:port name="soap12port" binding="tns:sc009SOAP12Binding"> <wsp:Policy> <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> ... </wsdl:port> </wsdl:service>
The above example is incorrect because the effective policies
for both the CreatePO and UpdatePO operations contain conflicting
assertions (a wsam:Addressing
assertion that is
unconstrained with regards to nnonymous/non-anonymous and a
wsam:Addressing
assertion that is constrained to just
non-anonymous) within the same alternative.
For example,
CORRECT:
<wsdl:binding name="sc009SOAP12Binding" type="tns:sc009PortType"> ... <wsdl:operation name="CreatePO"> <wsp:Policy> <wsam:Addressing> <wsp:Policy> <wsam:NonAnonymousResponses/> </wsp:Policy> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> <wsdl:operation name="GetPOStatus"> <wsp:Policy> <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> <wsdl:operation name="UpdatePO"> <wsp:Policy> <wsam:Addressing> <wsp:Policy> <wsam:NonAnonymousResponses/> </wsp:Policy> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> <wsdl:operation name="CancelPO"> <wsp:Policy> <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> ... </wsdl:operation> </wsdl:binding> <wsdl:service name="sc009Service"> <wsdl:port name="soap12port" binding="tns:sc009SOAP12Binding"> ... </wsdl:port> </wsdl:service>
The above example is correct. All of the operations in the soap12port of the s009Service require WS-Addressing. While the reponse EPRs for GetPOStatus and CancelPO are unconstrained, the response EPRs for the CreatePO and UpdatePO operations must be non-anonymous.
When used together, the wsam:AnonymousResponses
and
wsam:NonAnonymousResponses
nested policy assertions
could result in an effective policy that contradicts WS-Addressing
1.0 - Metadata (i.e. "request messages sent to this endpoint must
use response endpoint EPRs that simultaneously do and do not
contain the WS-Addressing anonymous URI"). The Profile restricts
the use of the wsam:AnonymousResponses
and
wsam:NonAnonymousResponses
nested policy assertions to
avoid this situation.
R1158 In a DESCRIPTION the effective policy for a
given endpoint MUST NOT contain both the
wsam:AnonymousResponses
and
wsam:NonAnonymousResponses
assertions within a single
policy alternative. CORE
NOT_TESTABLE_XPATH
In cases where there are multiple policy alternatives within the effective policy, some which violate R1158 and some which do not, consumers MAY consider those policy alternatives that do not violate R1158.
The Profile uses Web Services Description Language (WSDL) to enable the description of services as sets of endpoints operating on messages.
This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:
An instance of a Web service is required to make the contract that it operates under available in some fashion.
R0001 Either an INSTANCE's WSDL 1.1 description, its UDDI binding template, or both MUST be available to an authorized consumer upon request. CORE TESTABLE BP2703
Test Assertion: | BP2703 |
---|---|
Description: | The wsdl:definitions is a well-formed XML 1.0 document. The wsdl:definitions namespace has value: http://schemas.xmlsoap.org/wsdl/. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsdl:definitions is not a well-formed XML 1.0 document, or WSDL definition does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd for some element using the WSDL-SOAP binding namespace, or does not conform to the schema located at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd for some element using the WSDL namespace. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
This means that if an authorized consumer requests a service description of a conformant service instance, then the service instance provider must make the WSDL document, the UDDI binding template, or both available to that consumer. A service instance may provide run-time access to WSDL documents from a server, but is not required to do so in order to be considered conformant. Similarly, a service instance provider may register the instance provider in a UDDI registry, but is not required to do so to be considered conformant. In all of these scenarios, the WSDL contract must exist, but might be made available through a variety of mechanisms, depending on the circumstances.
WSDL 1.1, Section 2.1 defines the overall structure of an XML document for describing Web services. The Profile mandates the use of that structure, and places the following constraints on its use:
The normative schemas for WSDL appearing in Appendix 4 of the WSDL 1.1 specification have inconsistencies with the normative text of the specification. The Profile references new schema documents that have incorporated fixes for known errors.
R2028 A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this Profile) MUST be valid according to the XML Schema found at "http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd". CORE TESTABLE BP2705
Test Assertion: | BP2705 |
---|---|
Description: | The wsdl:definitions in namespace http://schemas.xmlsoap.org/wsdl/ is valid in accordance with the wsi version of the wsdl 1.1 schema at http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd . |
Target: |
|
co-Target: metadata |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The description file contains a WSDL definition which does not conform to the schema located at http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2029 A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "wsoap12" in this Profile) MUST be valid according to the XML Schema found at " http://schemas.xmlsoap.org/wsdl/soap12/wsdl11soap12-20060302.xsd". CORE TESTABLE BP2704
Test Assertion: | BP2704 |
---|---|
Description: | The wsdl:definitions using the WSDL SOAP binding namespace (prefixed "wsoap12" in this Profile) MUST be valid according to the XML Schema found at " http://schemas.xmlsoap.org/wsdl/soap12/wsdl11soap12.xsd ". |
Target: |
|
co-Target: metadata |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsdl:definitions is using the WSDL SOAP binding namespace (prefixed "wsoap12" in this Profile) in a way that is not valid according to the XML Schema found at " http://schemas.xmlsoap.org/wsdl/soap12/wsdl11soap12.xsd ". |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Although the Profile requires WSDL descriptions to be Schema valid, it does not require consumers to validate WSDL documents. It is the responsibility of a WSDL document's author to assure that it is Schema valid.
Some examples in WSDL 1.1 incorrectly show the WSDL import statement being used to import XML Schema definitions. The Profile clarifies use of the import mechanisms to keep them consistent and confined to their respective domains. Imported schema documents are also constrained by XML version and encoding requirements consistent to those of the importing WSDL documents.
R2001 A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description. CORE TESTABLE BP2101
Test Assertion: | BP2101 |
---|---|
Description: | Each wsdl:import statement is only used to import another WSDL description. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsdl:import element does not contain a reference to another WSDL description. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2803 In a DESCRIPTION, the namespace attribute of
the wsdl:import
MUST NOT be a relative URI.
CORE TESTABLE BP2803
Test Assertion: | BP2803 |
---|---|
Description: | The "namespace" attribute's value is not a relative URI. |
Target: |
|
Prerequisite: | BP2703 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsdl:import element's "namespace" attribute value is a relative URI. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2002 To import XML Schema Definitions, a DESCRIPTION MUST use the XML Schema "import" statement. CORE TESTABLE BP2101
Test Assertion: | BP2101 |
---|---|
Description: | Each wsdl:import statement is only used to import another WSDL description. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsdl:import element does not contain a reference to another WSDL description. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2003 A DESCRIPTION MUST use the XML Schema
"import" statement only within the xsd:schema
element
of the types section. CORE
TESTABLE BP2103
Test Assertion: | BP2103 |
---|---|
Description: | For the referenced definitions as well as all imported descriptions, The XML schema import statement is only used within an xsd:schema element. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A XML schema import element was found outside of an xsd:schema element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2004 In a DESCRIPTION the schemaLocation attribute of an xsd:import element MUST NOT resolve to any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema". CORE TESTABLE BP2106
Test Assertion: | BP2106 |
---|---|
Description: | In a DESCRIPTION the schemaLocation attribute of an xsd:import element MUST NOT resolve to any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema". |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | xsd:import element does not resolve to document whose root element is not "schema" from xsd namespace |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2009 An XML Schema directly or indirectly imported by a DESCRIPTION MAY include the Unicode Byte Order Mark (BOM). CORE NOT_TESTED
R2010 An XML Schema directly or indirectly imported by a DESCRIPTION MUST use either UTF-8 or UTF-16 encoding. CORE TESTABLE BP2202
Test Assertion: | BP2202 |
---|---|
Description: | All imported schema use UTF-8 or UTF-16 for the encoding. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The XML declaration statement within an imported XML Schema does not use expected encoding (UTF-8 or UTF-16). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2011 An XML Schema directly or indirectly imported by a DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation. CORE NOT_TESTABLE
For example,
INCORRECT:
<definitions name="StockQuote" targetNamespace="http://example.com/stockquote/definitions" xmlns:sq="http://example.com/stockquote" ... xmlns="http://schemas.xmlsoap.org/wsdl/"> <import namespace="http://example.com/stockquote" location="http://example.com/stockquote/schemas/stockquote.xsd"/> <message name="GetLastTradePriceInput"> <part name="body" element="sq:TradePriceRequest"/> </message> ... </definitions>
CORRECT:
<definitions name="StockQuote" targetNamespace="http://example.com/stockquote/definitions" xmlns:sq="http://example.com/stockquote" ... xmlns="http://schemas.xmlsoap.org/wsdl/"> <import namespace="http://example.com/stockquote/definitions" location="http://example.com/stockquote/definitions/stockquote.wsdl"/> <message name="GetLastTradePriceInput"> <part name="body" element="sq:TradePriceRequest"/> </message> ... </definitions>
CORRECT:
<definitions name="StockQuote" targetNamespace="http://example.com/stockquote/definitions" xmlns:sq="http://example.com/stockquote" xmlns:xsd="http://www.w3.org/2001/XMLSchema" ... xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <xsd:schema targetNamespace="http://example.com/stockquote"> <xsd:import namespace="http://example.com/stockquote" schemaLocation="http://example.com/stockquote/schemas/stockquote.xsd"/> <xsd:element name="TradePriceRequest" type="bt:PriceRequestType"/> </xsd:schema> </types> <message name="GetLastTradePriceInput"> <part name="body" element="sq:TradePriceRequest"/> </message> ... </definitions>
WSDL 1.1 is not clear about whether the location
attribute of the wsdl:import
statement is required, or
what its content is required to be.
R2007 A DESCRIPTION MUST specify a non-empty
location
attribute on the wsdl:import
element. CORE TESTABLE BP2098
Test Assertion: | BP2098 |
---|---|
Description: | The "location" attribute is specified for the wsdl:import element, and has a non-empty value. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsdl:import element does not have a "location" attribute, or has an empty value for the location attribute. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Although the wsdl:import
statement is modeled after
the xsd:import
statement, the location
attribute is required by wsdl:import
while the
corresponding attribute on xsd:import
,
schemaLocation
is optional. Consistent with
location
being required, its content is not intended
to be empty.
WSDL 1.1 is unclear about whether WSDL processors must actually
retrieve and process the WSDL document from the URI specified in
the location
attribute on the wsdl:import
statements it encounters.
R2008 A CONSUMER MAY, but need not, retrieve a
WSDL description from the URI specified in the location attribute
on a wsdl:import
element. CORE NOT_TESTED
The value of the location attribute of a
wsdl:import
element is a hint. A WSDL processor may
have other ways of locating a WSDL description for a given
namespace.
Example 3 in WSDL 1.1 Section 3.1 causes confusion regarding the
placement of wsdl:import
.
R2022 When they appear in a DESCRIPTION, wsdl:import
elements MUST precede all other elements from the WSDL namespace
except wsdl:documentation
. CORE TESTABLE BP2105
Test Assertion: | BP2105 |
---|---|
Description: | wsdl:import elements occur either as first children elements in the WSDL namespace of the wsdl:defintitions element, or they are only preceded by wsdl:documentation elements. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsdl:import element in the WSDL namespace under the wsdl:definitions element, is preceded by child elements other than wsdl:documentation elements. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2023 When they appear in a DESCRIPTION, wsdl:types
elements MUST precede all other elements from the WSDL namespace
except wsdl:documentation
and
wsdl:import
. CORE
TESTABLE BP2018
Test Assertion: | BP2018 |
---|---|
Description: | The wsdl:types elements occur either as first children in the WSDL namespace of the wsdl:definitions element, or they are only preceded by wsdl:documentation element(s) and/or wsdl:import(s) element(s). |
Target: |
|
Prerequisite: | BP2703 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | wsdl:types element(s) in the WSDL namespace of the wsdl:definitions element were preceded by child elements other than wsdl:documentation or wsdl:import elements. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
For example,
INCORRECT:
<definitions name="StockQuote" ... xmlns="http://schemas.xmlsoap.org/wsdl/"> <message name="GetLastTradePriceInput"> <part name="body" element="sq:TradePriceRequest"/> </message> ... <import namespace="http://example.com/stockquote/definitions" location="http://example.com/stockquote/definitions/stockquote.wsdl"/> ... <service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteSoap"> ... </port> </service> </definitions>
CORRECT:
<definitions name="StockQuote" ... xmlns="http://schemas.xmlsoap.org/wsdl/"> <import namespace="http://example.com/stockquote/definitions" location="http://example.com/stockquote/definitions/stockquote.wsdl"/> <message name="GetLastTradePriceInput"> <part name="body" element="sq:TradePriceRequest"/> </message> ... <service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteSoap"> ... </port> </service> </definitions>
INCORRECT:
<definitions name="StockQuote" ... xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/"> <message name="GetLastTradePriceInput"> <part name="body" element="sq:TradePriceRequest"/> </message> ... <service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteSoap"> ... </port> </service> <types> <xsd:schema targetNamespace="http://example.com/stockquote"> ... </xsd:schema> </types> </definitions>
CORRECT:
<definitions name="StockQuote" ... xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/"> <import namespace="http://example.com/stockquote/definitions" location="http://example.com/stockquote/definitions/stockquote.wsdl"/> <types> <xsd:schema targetNamespace="http://example.com/stockquote"> ... </xsd:schema> </types> <message name="GetLastTradePriceInput"> <part name="body" element="sq:TradePriceRequest"/> </message> ... <service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteSoap"> ... </port> </service> </definitions>
Neither WSDL 1.1 nor XML Schema 1.0 mandate a particular version of XML. For interoperability, WSDL documents and the schemas they import expressed in XML must use version 1.0.
R4004 A DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation. CORE TESTABLE BP2700
Test Assertion: | BP2700 |
---|---|
Description: | The wsdl:definitions is a well-formed XML 1.0 document. |
Target: |
|
co-Target: metadata |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsdl:definitions is not a well-formed XML 1.0 document. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Although published errata NE05 (see http://www.w3.org/XML/xml-names-19990114-errata) allows this namespace declaration to appear, some older processors considered such a declaration to be an error. This requirement ensures that conformant artifacts have the broadest interoperability possible.
R4005 A DESCRIPTION SHOULD NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". CORE TESTABLE BP2034
Test Assertion: | BP2034 |
---|---|
Description: | The candidate description does not contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". |
Target: |
|
Prerequisite: | BP2703 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | The candidate description contains the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace". |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
As this Profile allows for the use of protocol bindings other than HTTP, the transport is responsible for defining how encoding is handled as specified in Section 2.2 for Simple SOAP and XOP encoded messages using HTTP. This applies to Sections 4.2.8 and 4.2.9. For HTTP, transport protocol constraints are identified in RFC 3023 .
XML 1.0 allows documents that use the UTF-8 character encoding to include a BOM; therefore, description processors must be prepared to accept them.
R4002 A DESCRIPTION MAY include the Unicode Byte Order Mark (BOM). CORE NOT_TESTED
The Profile consistently requires either UTF-8 or UTF-16 encoding for both SOAP and WSDL.
R4003 A DESCRIPTION MUST use either UTF-8 or UTF-16 encoding. CORE TESTABLE BP2201
Test Assertion: | BP2201 |
---|---|
Description: | The XML declaration statement uses UTF-8 or UTF-16 for the encoding. |
Target: |
|
co-Target: metadata |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | XML declaration statement within WSDL document does not use expected encoding (UTF-8 or UTF-16). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Namespace coercion on wsdl:import
is disallowed by
the Profile.
R2005 The targetNamespace
attribute
on the wsdl:definitions
element of a description that
is being imported MUST have same the value as the
namespace
attribute on the wsdl:import
element in the importing DESCRIPTION. CORE TESTABLE BP2104
Test Assertion: | BP2104 |
---|---|
Description: | The targetNamespace attribute on the wsdl:definitions element for the imported WSDL description has the same value as the namespace attribute on the wsdl:import element that imported the WSDL description. |
Target: |
|
Prerequisite: | BP2101 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The targetNamespace attribute on the wsdl:definitions element for an imported WSDL description does not have the same value as the namespace attribute on the wsdl:import element that imported the WSDL description. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The WSDL 1.1 schema and the WSDL 1.1 specification are
inconsistent with respect to where wsdl:documentation
elements may be placed.
R2030 In a DESCRIPTION the wsdl:documentation
element MAY be present as the first child element of
wsdl:import
, wsdl:part
and
wsdl:definitions
in addition to the elements cited in
the WSDL 1.1 specification. CORE
NOT_TESTED
Requiring support for WSDL extensions that are not explicitly specified by this or another WS-I Profile can lead to interoperability problems with development tools that have not been instrumented to understand those extensions.
R2025 A DESCRIPTION containing WSDL extensions MUST NOT use them to contradict other requirements of the Profile. CORE NOT_TESTABLE
R2026 A DESCRIPTION SHOULD NOT include extension
elements with a wsdl:required
attribute value of
"true" on any WSDL construct (wsdl:binding
,
wsdl:portType
, wsdl:message
,
wsdl:types
or wsdl:import
) that claims
conformance to the Profile. CORE
TESTABLE BP2123
Test Assertion: | BP2123 |
---|---|
Description: | Contained WSDL extension elements do not use the wsdl:required attribute value of "true". |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | An extension element within a WSDL element that claims conformance to the Basic Profile has a wsdl:required attribute with a value of "true". |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2027 If during the processing of a description,
a consumer encounters a WSDL extension element that has a
wsdl:required
attribute with a boolean value of "true"
that the consumer does not understand or cannot process, the
CONSUMER MUST fail
processing. CORE NOT_TESTABLE
Development tools that consume a WSDL description and generate software for a Web service instance might not have built-in understanding of an unknown WSDL extension. Hence, use of required WSDL extensions should be avoided. Use of a required WSDL extension that does not have an available specification for its use and semantics imposes potentially insurmountable interoperability concerns for all but the author of the extension. Use of a required WSDL extension that has an available specification for its use and semantics reduces, but does not eliminate the interoperability concerns that lead to this refinement.
For the purposes of the Profile, all elements in the "http://schemas.xmlsoap.org/wsdl/" namespace are extensible via element as well as attributes. As a convenience, WS-I has published a version of the WSDL 1.1 schema that reflects this capability at: http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd
WSDL 1.1, Section 2.2 defines the
wsdl:types
element to enclose data type definitions
that are relevant to the Web service described. The Profile places
the following constraints pertinent to those portions of the
content of the wsdl:types
element that are referred to
by WSDL elements that make Profile conformance claims:
XML Schema requires each QName reference to use either the
target namespace, or an imported namespace (one marked explicitly
with an xsd:import
element). QName references to
namespaces represented only by nested imports are not allowed.
WSDL 1.1 is unclear as to which schema target namespaces are
suitable for QName references from a WSDL element. The Profile
allows QName references from WSDL elements both to the target
namespace defined by the xsd:schema
element, and to
imported namespaces. QName references to namespaces that are only
defined through a nested import are not allowed.
R2101 A DESCRIPTION MUST NOT use QName references to WSDL components in namespaces that have been neither imported, nor defined in the referring WSDL document. CORE TESTABLE BP2416
Test Assertion: | BP2416 |
---|---|
Description: | A DESCRIPTION MUST NOT use QName references to WSDL components in namespaces that have been neither imported, nor defined in the referring WSDL document. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | This DESCRIPTION uses QName references to WSDL components in namespaces that are neither imported, nor defined in the referring WSDL document |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2102 A QName reference to a Schema component in
a DESCRIPTION MUST use the
namespace defined in the targetNamespace
attribute on
the xsd:schema
element, or to a namespace defined in
the namespace
attribute on an xsd:import
element within the xsd:schema
element. CORE TESTABLE BP2417
Test Assertion: | BP2417 |
---|---|
Description: | A QName reference to a Schema component in a DESCRIPTION MUST use the namespace defined in the targetNamespace attribute on the xsd:schema element, or to a namespace defined in the namespace attribute on an xsd:import element within the xsd:schema element. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A QName reference to a Schema component in a DESCRIPTION does not use the namespace defined in the targetNamespace attribute on the xsd:schema element, or a namespace defined in the namespace attribute on an xsd:import element within the xsd:schema element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Requiring a targetNamespace on all xsd:schema elements that are
children of wsdl:types
is a good practice, places a
minimal burden on authors of WSDL documents, and avoids the cases
that are not as clearly defined as they might be.
R2105 All xsd:schema
elements
contained in a wsdl:types
element of a DESCRIPTION MUST have a
targetNamespace
attribute with a valid and non-null
value, UNLESS the xsd:schema
element has
xsd:import
and/or xsd:annotation
as its
only child element(s). CORE
TESTABLE BP2107
Test Assertion: | BP2107 |
---|---|
Description: | The xsd:schema element contains a targetNamespace attribute with a valid and non-null value unless the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s). |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A xsd:schema element contained in a wsdl:types element does not have a targetNamespace attribute with a valid and non-null value, while having child element(s) other than xsd:import or xsd:annotation. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The recommendations in WSDL 1.1 Section 2.2 for declaration of array types have been interpreted in various ways, leading to interoperability problems. Further, there are other clearer ways to declare arrays.
R2110 In a DESCRIPTION, declarations MUST NOT extend
or restrict the soapenc:Array
type. CORE TESTABLE BP2108b
Test Assertion: | BP2108b |
---|---|
Description: | The type soapenc:Array does not appear in these declarations, and the wsdl:arrayType attribute is not used in the type declaration. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An Array declaration uses - restricts or extends - the soapenc:Array type, or the wsdl:arrayType attribute is used in the type declaration. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2111 In a DESCRIPTION, declarations MUST NOT use
wsdl:arrayType
attribute in the type declaration.
CORE TESTABLE BP2108a
Test Assertion: | BP2108a |
---|---|
Description: | The type soapenc:Array does not appear in these declarations, and the wsdl:arrayType attribute is not used in the type declaration. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An Array declaration uses - restricts or extends - the soapenc:Array type, or the wsdl:arrayType attribute is used in the type declaration. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2112 In a DESCRIPTION, elements SHOULD NOT be named using the convention ArrayOfXXX. CORE TESTABLE BP2110
Test Assertion: | BP2110 |
---|---|
Description: | The declaration does not use the naming convention ArrayOfXXX. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | A declaration is using the convention ArrayOfXXX. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2113 An ENVELOPE MUST NOT include the
soapenc:arrayType
attribute. CORE TESTABLE BP1204
Test Assertion: | BP1204 |
---|---|
Description: | The soap12:Body of the envelope does not contain the soapenc:arrayType attribute. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The soap12:Body of an envelope contains the soapenc:arrayType attribute. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
For example,
INCORRECT:
Given the WSDL Description:
<xsd:element name="MyArray2" type="tns:MyArray2Type"/> <xsd:complexType name="MyArray2Type" xmlns:soapenc="http://www.w3.org/2003/05/soap-encoding" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <xsd:complexContent> <xsd:restriction base="soapenc:Array"> <xsd:sequence> <xsd:element name="x" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="tns:MyArray2Type[]"/> </xsd:restriction> </xsd:complexContent> </xsd:complexType>
The envelope would serialize as (omitting namespace declarations for clarity):
<MyArray2 soapenc:arrayType="tns:MyArray2Type[]"> <x>abcd</x> <x>efgh</x> </MyArray2>
CORRECT:
Given the WSDL Description:
<xsd:element name="MyArray1" type="tns:MyArray1Type"/> <xsd:complexType name="MyArray1Type"> <xsd:sequence> <xsd:element name="x" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
The envelope would serialize as (omitting namespace declarations for clarity):
<MyArray1> <x>abcd</x> <x>efgh</x> </MyArray1>
The names defined by schemas and the names assigned to WSDL definitions are in separate symbol spaces.
R2114 The target namespace for WSDL definitions and the target namespace for schema definitions in a DESCRIPTION MAY be the same. CORE NOT_TESTED
The schema components of all the xs:schema
children, and their imports and includes, of the wsdl:types element
comprise a single symbol space containing all the global element
declarations. Thus, when global element declarations share a
qualified name, a single component will be represented in the
symbol space. If two declarations are identical, there is no
ambiguity in the structure of the component, but if the
declarations differ, it is indeterminate as to which of the
declarations will be represented, which may lead to
interoperability problems. Because defining an equivalence
algorithm is impractical, this requirement warns against any
appearance of declarations with the same qualified name. However,
duplicate declarations are not strictly prohibited, as user
inspection may determine that two declarations are actually
identical (e.g. they were imported from the same set of components)
and thus are unlikely to cause interoperability problems.
R2115 A DESCRIPTION SHOULD NOT contain multiple global element declarations that share the same qualified name. CORE TESTABLE BP2124
Test Assertion: | BP2124 |
---|---|
Description: | No two global element declarations share the same qualified name. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | Two or more global element declarations share the same qualified name. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The schema components of all the xs:schema children, and their imports and includes, of the wsdl:types element comprise single symbol spaces containing all the type definitions. Thus, when type definitions share a qualified name, a single component will be represented in the symbol space. If two definitions are identical, there is no ambiguity in the structure of the component, but if the definitions differ, it is indeterminate as to which of the definitions will be represented, which may lead to interoperability problems. Because defining an equivalence algorithm is impractical, this requirement warns against any appearance of definitions with the same qualified name. However, duplicate definitions are not strictly prohibited, as user inspection may determine that two definitions are actually identical (e.g. they were imported from the same set of components) and thus are unlikely to cause interoperability problems.
R2116 A DESCRIPTION SHOULD NOT contain multiple type definitions that share the same qualified name. CORE TESTABLE BP2125
Test Assertion: | BP2125 |
---|---|
Description: | No two type definitions share the same qualified name. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | preferred |
Error Message: | Two or more type definitions share the same qualified name. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
WSDL 1.1, Section 2.3 defines the
wsdl:message
elements that are used to represent
abstract definitions of the data being transmitted. It uses
wsdl:binding
elements to define how the abstract
definitions are bound to a specific message serialization. The
Profile places the following constraints on
wsdl:message
elements and on how conformant
wsdl:binding
elements may use
wsdl:message
element(s).
In this section the following definitions are used to make the requirements more compact and easier to understand.
Definition: rpc-literal binding
An "rpc-literal binding" is a wsdl:binding
element
whose child wsdl:operation
elements are all
rpc-literal operations.
An "rpc-literal operation" is a wsdl:operation
child element of wsdl:binding
whose
wsoap12:body
descendant elements specify the
use
attribute with the value "literal", and
either:
style
attribute with the value "rpc" is
specified on the child wsoap12:operation
element;
orstyle
attribute is not present on the child
wsoap12:operation
element, and the
wsoap12:binding
element in the enclosing
wsdl:binding
specifies the style
attribute with the value "rpc".Definition: document-literal binding
A "document-literal binding" is a wsdl:binding
element whose child wsdl:operation
elements are all
document-literal operations.
A "document-literal operation" is a wsdl:operation
child element of wsdl:binding
whose
wsoap12:body
descendent elements specifies the
use
attribute with the value "literal" and,
either:
style
attribute with the value "document" is
specified on the child wsoap12:operation
element;
orstyle
attribute is not present on the child
wsoap12:operation
element, and the
wsoap12:binding
element in the enclosing
wsdl:binding
specifies the style
attribute with the value "document"; orstyle
attribute is not present on both the
child wsoap12:operation
element and the
wsoap12:binding
element in the enclosing
wsdl:binding
.There are various interpretations about how many
wsdl:part
elements are permitted or required for
document-literal and rpc-literal bindings and how they must be
defined.
R2201 A document-literal binding in a
DESCRIPTION MUST, in each of
its wsoap12:body
element(s), have at most one part
listed in the parts
attribute, if the
parts
attribute is specified. CORE TESTABLE BP2111
Test Assertion: | BP2111 |
---|---|
Description: | If the "parts" attribute is present, then the wsoap12:body element(s) have at most one part listed in the parts attribute. |
Target: |
|
Prerequisite: | BP2017 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | One or more wsoap12:body element(s) in a document-literal soabinding does not have at most one part listed in the parts attribute. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2210 If a document-literal binding in a
DESCRIPTION does not specify
the parts
attribute on a wsoap12:body
element, the corresponding abstract wsdl:message
MUST
define zero or one wsdl:part
s. CORE TESTABLE BP2119
Test Assertion: | BP2119 |
---|---|
Description: | If it does not specify the parts attribute on a wsoap12:body element, the corresponding abstract wsdl:message defines zero or one wsdl:part. |
Target: |
|
Prerequisite: | BP2017 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A document-literal binding which does not specify the parts attribute, has more than one wsdl:part in the associated wsdl:message element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2202 A wsdl:binding
in a
DESCRIPTION MAY contain
wsoap12:body
element(s) that specify that zero parts
form the soap12:Body
. CORE NOT_TESTED
R2203 An rpc-literal binding in a DESCRIPTION MUST refer, in its
wsoap12:body
element(s), only to
wsdl:part
element(s) that have been defined using the
type
attribute. CORE
TESTABLE BP2013
Test Assertion: | BP2013 |
---|---|
Description: | The binding (in wsoap12:body elements) only refers to part elements that have been defined using the "type" attribute |
Target: |
|
Prerequisite: | BP2017 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | soabinding (in wsoap12:body elements) refers to part(s) that do not have the "type" attribute. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2211 An ENVELOPE described with an rpc-literal
binding MUST NOT have the xsi:nil
attribute with a
value of "1" or "true" on the part accessors. CORE TESTABLE BP1211a BP1211b
Test Assertion: | BP1211a |
---|---|
Description: | Part accessor elements in the envelope do not have an xsi:nil attribute with a value of "1" or "true". |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | Envelope referenced by an rpc-literal binding has part accessor elements with an xsi:nil attribute with a value of "1" or "true". |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1211b |
---|---|
Description: | Part accessor elements in the response envelope do not have an xsi:nil attribute with a value of "1" or "true". |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | response Envelope referenced by an rpc-literal binding has part accessor elements with an xsi:nil attribute with a value of "1" or "true". |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2207 A wsdl:message
in a
DESCRIPTION MAY contain
wsdl:part
s that use the elements
attribute provided those wsdl:part
s are not referred
to by a wsoap12:body
in an rpc-literal binding.
CORE NOT_TESTED
R2204 A document-literal binding in a
DESCRIPTION MUST refer, in
each of its wsoap12:body
element(s), only to
wsdl:part
element(s) that have been defined using the
element
attribute. CORE TESTABLE BP2012
Test Assertion: | BP2012 |
---|---|
Description: | A doc//wsoap12:body/@use != 'literal') and (count($myOpBinding/..//wsoap12:body) = count($myOpBinding/..//wsoap12:body/@use)) and not($myOpBinding/..//wsoap12:*/@style = 'rpc') and $myOpBinding/wsdl:output/wsoap12:body[@parts and (@parts = '' or @parts = ' ' )] ument-literal binding only refers in wsoap12:body elements to part elements that have been defined using the "element" attribute. |
Target: |
|
Prerequisite: | BP2017 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The binding (in wsoap12:body elements) refers to part(s) of a soap12:Body element that do not have the "element" attribute. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2208 A binding in a DESCRIPTION MAY contain
wsoap12:header
element(s) that refer to
wsdl:part
s in the same wsdl:message
that
are referred to by its wsoap12:body
element(s).
CORE NOT_TESTED
R2212 An ENVELOPE described using an rpc-literal
binding MUST contain exactly one part accessor element for each of
the wsdl:part
elements bound to the
wsoap12:body
element in the rpc-literal binding
corresponding to the envelope. CORE
TESTABLE BP1212a BP1212b
Test Assertion: | BP1212a |
---|---|
Description: | The Envelope of request message contains exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The content of the soap12:Body element of request message is inconsistent with its description. The envelope does not contain exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1212b |
---|---|
Description: | The Envelope of response message contains exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The content of the soap12:Body element of resonse message is inconsistent with its description. The envelope does not contain exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2213 In a doc-literal description where the value of the parts attribute of wsoap12:body is an empty string, the corresponding ENVELOPE MUST have no element content in the soap12:Body element. CORE TESTABLE BP1213a BP1213b
Test Assertion: | BP1213a |
---|---|
Description: | The request message envelope has no element content in the soap12:Body element if the value of the parts attribute of the wsoap12:body is an empty string in the corresponding doc-literal description. |
Target: |
|
co-Target: myOpBinding |
|
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The request message soap12:Body element must be empty when, in the corresponding doc-literal description, the value of the parts attribute of wsoap12:body is an empty string. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1213b |
---|---|
Description: | The response message envelope has no element content in the soap12:Body element if the value of the parts attribute of the wsoap12:body is an empty string in the corresponding doc-literal description. |
Target: |
|
co-Target: myOpBinding |
|
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The response message soap12:Body element must be empty when, in the corresponding doc-literal description, the value of the parts attribute of wsoap12:body is an empty string. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2214 In a rpc-literal description where the value of the parts attribute of wsoap12:body is an empty string, the corresponding ENVELOPE MUST have no part accessor elements. CORE TESTABLE BP1214a BP1214b
Test Assertion: | BP1214a |
---|---|
Description: | The request message envelope does not contain any part accessor elements if the value of the parts attribute of the wsoap12:body is an empty string in the corresponding rpc-literal description |
Target: |
|
co-Target: myOpBinding |
|
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The content of the request message soap12:Body element is inconsistent with its description. The envelope must not have any part accessor elements when, in the corresponding rpc-literal description, the value of the parts attribute of wsoap12:body is an empty string. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1214b |
---|---|
Description: | The response message envelope does not contain any part accessor elements if the value of the parts attribute of the wsoap12:body is an empty string in the corresponding rpc-literal description |
Target: |
|
co-Target: myOpBinding |
|
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The content of the response message soap12:Body element is inconsistent with its description. The envelope must not have any part accessor elements when, in the corresponding rpc-literal description, the value of the parts attribute of wsoap12:body is an empty string. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Use of wsdl:message
elements with zero parts is
permitted in Document styles to permit operations that can send or
receive envelopes with empty soap12:Body
s. Use of
wsdl:message
elements with zero parts is permitted in
RPC styles to permit operations that have no (zero) parameters
and/or a return value.
For document-literal bindings, the Profile requires that at most
one part, abstractly defined with the element
attribute, be serialized into the soap12:Body
element.
When a wsdl:part
element is defined using the
type
attribute, the serialization of that part in a
message is equivalent to an implicit (XML Schema) qualification of
a minOccurs
attribute with the value "1", a
maxOccurs
attribute with the value "1" and a
nillable
attribute with the value "false".
It is necessary to specify the equivalent implicit qualification
because the wsdl:part
element does not allow one to
specify the cardinality and nillability rules. Specifying the
cardinality and the nillability rules facilitates interoperability
between implementations. The equivalent implicit qualification for
nillable attribute has a value of "false" because if it is
specified to be "true" one cannot design a part whereby the client
is always required to send a value. For applications that want to
allow the wsdl:part
to to be nillable, it is expected
that applications will generate a complexType wrapper and specify
the nillability rules for the contained elements of such a
wrapper.
There are several interpretations for how wsdl:part
elements that describe wsoap12:fault
,
wsoap12:header
, and wsoap12:headerfault
may be defined.
R2205 A wsdl:binding
in a
DESCRIPTION MUST refer, in
each of its wsoap12:header
,
wsoap12:headerfault
and wsoap12:fault
elements, only to wsdl:part
element(s) that have been
defined using the element
attribute. CORE TESTABLE BP2113
Test Assertion: | BP2113 |
---|---|
Description: | When they contain references to message parts, the wsoap12:header, wsoap12:headerfault and wsoap12:fault elements only refer to wsdl:part element(s) that have been defined using the "element" attribute. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsoap12:header, wsoap12:headerfault or wsoap12:fault elements refer to wsd:part element(s) that are not defined using only the "element" attribute. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Because faults and headers do not contain parameters,
wsoap12:fault
, wsoap12:header
and
wsoap12:headerfault
assume, per WSDL 1.1, that the
value of the style
attribute is "document". R2204
requires that all wsdl:part
elements with a
style
attribute whose value is "document" that are
bound to wsoap12:body
be defined using the
element
attribute. This requirement does the same for
wsoap12:fault
, wsoap12:header
and
wsoap12:headerfault
elements.
WSDL 1.1 is not explicit about whether it is permissible for a
wsdl:binding
to leave the binding for portions of the
content defined by a wsdl:portType
unspecified.
R2209 A wsdl:binding
in a
DESCRIPTION SHOULD bind every
wsdl:part
of a wsdl:message
in the
wsdl:portType
to which it refers to one of
wsoap12:body
, wsoap12:header
,
wsoap12:fault
or wsoap12:headerfault
.
CORE TESTABLE BP2114
Test Assertion: | BP2114 |
---|---|
Description: | Every wsdl:part from each wsdl:message in the associated wsdl:portType is referenced either by the wsoap12:body, wsoap12:header, wsoap12:fault, or wsoap12:headerfault. |
Target: |
|
Predicate: |
every $op in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType[local-name-from-QName(resolve-QName(xsd:string($bing/@type),$bing)) = @name]/wsdl:operation satisfies some $bop in $bing/wsdl:operation[@name = $op/@name] satisfies ( ( ($bop/wsdl:input/wsoap12:body[not(@parts)]) or ( every $mpart in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name = local-name-from-QName(resolve-QName(xsd:string($op/wsdl:input/@message),$op/wsdl:input))]/wsdl:part satisfies ( fn:exists(fn:index-of(tokenize($bop/wsdl:input/wsoap12:body/@parts,'\s+'), $mpart/@name)) or (some $extra in $bing/wsdl:operation/wsdl:*/wsoap12:*[local-name-from-QName(resolve-QName(xsd:string(@message),.)) = $mpart/../@name] satisfies $mpart/@name = $extra/@part )) ) ) and ( not($op/wsdl:output) or ($bop/wsdl:output/wsoap12:body[not(@parts)]) or ( every $mpart in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name = local-name-from-QName(resolve-QName(xsd:string($op/wsdl:output/@message),$op/wsdl:output))]/wsdl:part satisfies ( fn:exists(fn:index-of(tokenize($bop/wsdl:output/wsoap12:body/@parts,'\s+'), $mpart/@name)) or (some $extra in $bing/wsdl:operation/wsdl:*/wsoap12:*[local-name-from-QName(resolve-QName(xsd:string(@message),.)) = $mpart/../@name] satisfies $mpart/@name = $extra/@part )) ) ) and ( not($op/wsdl:fault) or (every $flt in $op/wsdl:fault satisfies $flt/@name = $bop/wsdl:fault/wsoap12:fault/@name) ) ) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsdl:binding does not bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of wsoap12:body, wsoap12:header, wsoap12:fault or wsoap12:headerfault. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
A portType defines an abstract contract with a named set of
operations and associated abstract messages. Although not
disallowed, it is expected that every part of the abstract input,
output and fault messages specified in a portType is bound to
wsoap12:body
or wsoap12:header
(and so
forth) as appropriate when using the SOAP binding as defined in
WSDL 1.1 Section 3. Un-bound wsdl:parts should be ignored.
Examples 4 and 5 in WSDL 1.1 Section 3.1 incorrectly show the
use of XML Schema types (e.g. "xsd:string") as a valid value for
the element
attribute of a wsdl:part
element.
R2206 A wsdl:message
in a
DESCRIPTION containing a
wsdl:part
that uses the element
attribute
MUST refer, in that attribute, to a global element declaration.
CORE TESTABLE BP2115
Test Assertion: | BP2115 |
---|---|
Description: | An "element" attribute on any wsdl:part element refers to a global element declaration. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsdl:message element containing a wsdl:part element that uses the "element" attribute does not refer, via that attribute, to a global element declaration. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
For example,
INCORRECT:
<message name="GetTradePriceInput"> <part name="tickerSymbol" element="xsd:string"/> </message>
CORRECT:
<message name="GetTradePriceInput"> <part name="body" element="tns:SubscribeToQuotes"/> </message>
WSDL 1.1, Section 2.4 defines the
wsdl:portType
elements that are used to group a set of
abstract operations. The Profile places the following constraints
on conformant wsdl:portType
element(s):
Permitting the use of parameterOrder
helps code
generators in mapping between method signatures and messages on the
wire.
R2301 The order of the elements in the
soap12:Body
of an ENVELOPE MUST be the same as that of the
wsdl:parts
in the wsdl:message
that
describes it for each of the wsdl:part
elements bound
to the envelope's corresponding wsoap12:body
element.
CORE TESTABLE BP1111a BP1111b BP1012a BP1012b
Test Assertion: | BP1111a |
---|---|
Description: | The content of the request message envelope matches the definition in the WSDL document. In case of a doc-lit binding, the child element of soap12:body is an instance of the global element declaration referenced by the corresponding wsdl:part. It is assumed the doc-lit binding has only 1 part. (NOTE: BP211 assumed prereq for the cotarget) |
Target: |
|
co-Target: myOpBinding |
|
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The content of the request message envelope associated with a doc-lit WSDL binding does not match the wsdl:message definition. the child element of soap12:body is not an instance of the global element declaration referenced by the corresponding wsdl:part. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1111b |
---|---|
Description: | The content of the response message envelope matches the definition in the WSDL document. In case of a doc-lit binding, the child element of soap12:Body is an instance of the global element declaration referenced by the corresponding wsdl:part. It is assumed the doc-lit binding has only 1 part. (NOTE: BP211 assumed prereq for the cotarget) |
Target: |
|
co-Target: myOpBinding |
|
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The content of the response message envelope does not match the wsdl:message definition. the child element of soap12:Body is not an instance of the global element declaration referenced by the corresponding wsdl:part. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1012a |
---|---|
Description: | The content of the request message envelope matches the definition in the WSDL document for rpc-lit binding. The order of the part elements in the soap12:Body of the wired message, is same as that of the wsdl:partS, in the wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The content of the request message envelope does not match the wsdl:message definition for rpc/lit binding. The order of parts in soap12:Body does not match the order of wsdl:partS in wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | BP1012b |
---|---|
Description: | The content of the response message envelope matches the definition in the WSDL document for rpc-lit binding. The order of the part elements in the soap12:Body of the wired message, is same as that of the wsdl:partS, in the wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The content of the response message envelope does not match the wsdl:message definition for rpc/lit binding. The order of parts in soap12:Body does not match the order of wsdl:partS in wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding wsoap12:body element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2302 A DESCRIPTION MAY use the
parameterOrder
attribute of an
wsdl:operation
element to indicate the return value
and method signatures as a hint to code generators. CORE NOT_TESTED
Solicit-Response and Notification operations are not well defined by WSDL 1.1; furthermore, WSDL 1.1 does not define bindings for them.
R2303 A DESCRIPTION MUST NOT use Solicit-Response
and Notification type operations in a wsdl:portType
definition. CORE TESTABLE BP2208
Test Assertion: | BP2208 |
---|---|
Description: | The wsdl:operation element is either a WSDL request/response or a one-way operation (no Notification or Sollicit-Response). |
Target: |
|
Prerequisite: | BP2703 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | wsdl:operation was not a request/response or one-way operation. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Operation name overloading in a wsdl:portType
is
disallowed by the Profile.
R2304 A wsdl:portType
in a
DESCRIPTION MUST have
operations with distinct values for their name
attributes. CORE TESTABLE BP2010
Test Assertion: | BP2010 |
---|---|
Description: | name attributes of Operations are unique in the wsdl:portType definition |
Target: |
|
Prerequisite: | BP2703 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | name attributes are not unique within the portType definition. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |