This revision:
Latest revision:
http://mp.ws-i.org/apps/org/workgroup/bpwg/download.php/BasicProfile-2.0-ED.html
Editors:
Robert Chumbley , IBM
Jacques Durand , Fujitsu
Gilbert Pilz , Oracle
Tom Rutt , Fujitsu
Administrative contact:
Copyright © 2002-2009 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
an editors' copy that has no official standing; it is not complete. Other
documents may supersede this document. Discussion of this document takes place
on the Member-only mailing list, wsi_wsbasic@lists.ws-i.org.
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. Enumeration
of Faults
4.7.13. Type
and Name of SOAP Binding Elements
4.7.14. name
Attribute on Faults
4.7.15. Omission
of the use Attribute
4.7.16. Default
for use Attribute
4.7.17. Consistency
of Envelopes with Descriptions
4.7.18. Response
Wrappers
4.7.19. Part
Accessors
4.7.20. Namespaces
for Children of Part Accessors
4.7.21. Required
Headers
4.7.22. Allowing
Undescribed Headers
4.7.23. Ordering
Headers
4.7.24. Describing
action Parameter on the Content-Type MIME Header
4.7.25. SOAPAction
HTTP Header
4.7.26. SOAP
Binding Extensions
4.8. http://mp.ws-i.org/apps/org/workgroup/bpwg/download.php/5013/latest/BasicProfile-2.0-ED.html#WSDL11SOAP12SA
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.
No guarantee of interoperability
It is impossible to
completely guarantee the interoperability of a particular service. However, the
Profile does address the most common problems that implementation experience
has revealed to date.
Application semantics
Although communication
of application semantics can be facilitated by the technologies that comprise
the Profile, assuring the common understanding of those semantics is not
addressed by it.
Testability
When possible, the
Profile makes statements that are testable. However, such testability is not
required. Preferably, testing is achieved in a non-intrusive manner (e.g.,
examining artifacts "on the wire").
Strength of requirements
The Profile makes strong
requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate
cases where such a requirement cannot be met, conditional requirements (e.g.,
SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce
ambiguity and mismatches between implementations.
Restriction vs. relaxation
When amplifying the
requirements of referenced specifications, the Profile may restrict them, but
does not relax them (e.g., change a MUST to a MAY).
Multiple mechanisms
If a referenced
specification allows multiple mechanisms to be used interchangeably, the
Profile selects those that are well-understood, widely implemented and useful.
Extraneous or underspecified mechanisms and extensions introduce complexity and
therefore reduce interoperability.
Future compatibility
When possible, the
Profile aligns its requirements with in-progress revisions to the
specifications it references. This aids implementers by enabling a graceful
transition, and assures that WS-I does not 'fork' from these efforts. When the
Profile cannot address an issue in a specification it references, this
information is communicated to the appropriate body to assure its
consideration.
Compatibility with deployed services
Backwards compatibility
with deployed Web services is not a goal for the Profile, but due consideration
is given to it; the Profile does not introduce a change to the requirements of
a referenced specification unless doing so addresses specific interoperability
issues.
Focus on interoperability
Although there are
potentially a number of inconsistencies and design flaws in the referenced
specifications, the Profile only addresses those that affect interoperability.
Conformance targets
Where possible, the
Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP
messages) rather than the producing or consuming software's behaviors or roles.
Artifacts are concrete, making them easier to verify and therefore making
conformance easier to understand and less error-prone.
Lower-layer interoperability
The Profile speaks to
interoperability at the application layer; it assumes that interoperability of
lower-layer protocols (e.g., TCP, IP, Ethernet) is adequate and
well-understood. Similarly, statements about application-layer substrate
protocols (e.g., SSL/TLS, HTTP) are only made when there is an issue affecting
Web services specifically; WS-I does not attempt to assure the interoperability
of these protocols as a whole. This assures that WS-I's expertise in and focus
on Web services standards is used effectively.
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:
Note Item: |
|
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. 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.
Requirement
identifiers can be considered to be namespace qualified, in such a way as to be
compatible with QNames from Namespaces
in XML. If there is no explicit namespace prefix on a requirement's
identifier (e.g., "R9999" as opposed to "bp10:R9999"), it
should be interpreted as being in the namespace identified by the conformance
URI of the document section it occurs in. If it is qualified, the prefix should
be interpreted according to the namespace mappings in effect, as documented
below.
Some requirements
clarify the referenced specification(s), but do not place additional
constraints upon implementations. For convenience, clarifications are annotated
in the following manner: C
Some requirements
are derived from ongoing standardization work on the referenced
specification(s). For convenience, such forward-derived statements are
annotated in the following manner: xxxx, where "xxxx"
is an identifier for the specification (e.g., "WSDL20" for WSDL Version
2.0). Note that because such work was not complete when this document was
published, the specification that the requirement is derived from may change;
this information is included only as a convenience to implementers.
As noted above,
some requirements may present compatibility issues (whether forwards or
backwards) with previously published versions of the profile. For convenience,
such requirements are annotated in the following manner: Compat
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
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; i.e., although this requirement
must be met to maintain conformance in most cases, there are some situations
where there may be valid reasons for it not being met (which are explained in
the requirement itself, or in its accompanying text).
Each requirement
statement contains exactly one requirement level keyword (e.g.,
"MUST") and one conformance target keyword (e.g.,
"MESSAGE"). The conformance target keyword appears in bold text (e.g.
" MESSAGE"). Other conformance targets appearing in non-bold
text are being used strictly for their definition and NOT as a conformance
target. Additional text may be included to illuminate a requirement or group of
requirements (e.g., rationale and examples); however, prose surrounding
requirement statements must not be considered in determining conformance.
Definitions of
terms in the Profile are considered authoritative for the purposes of
determining conformance.
None of the
requirements in the Profile, regardless of their conformance level, should be
interpreted as limiting the ability of an otherwise conforming implementation
to apply security countermeasures in response to a real or perceived threat
(e.g., a denial of service attack).
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:
The conformance
claim URI for this Profile is " http://ws-i.org/profiles/basic/2.0 "
.
This section of
the Profile incorporates the following specifications by reference, and defines
extensibility points within them:
Test Assertion: |
|
Description: |
The soap12:Envelope contains other header blocks. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[soap12:Header[some $hbloc in child::* satisfies not(fn:namespace-uri($hbloc) = 'http://www.w3.org/2005/08/addressing') and not($hbloc/attribute::*:IsReferenceParameter) ]] |
Predicate: |
fn:true() |
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 |
|
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: § passed § failed § warning § notApplicable § notRelevant § missingInput § undetermined 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). 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: § mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT,
REQUIRED (and sometimes MAY NOT) § preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT
RECOMMENDED § permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: § @true attribute: may take values among {passed, failed, warning, undetermined}
(default is 'passed') § @false attribute: may take values among {passed, failed,
warning, undetermined} (default is 'failed') The reported outcomes
have the following meaning: § passed: the target passes the test and can be considered as fulfilling
the profile feature. § failed: the target fails the test and can be considered as violating
(or not exhibiting) the profile feature. § warning: the test result is inconclusive. There is a possibility of
profile requirement violation, that deserved further investigation. § undetermined: the test result is inconclusive for this predicate value. 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: § notRelevant: the target failed the prerequisite condition and therefore
does not qualify for further testing (i.e. the predicate expression is NOT
evaluated on it). § missingInput: a cotarget expression returned an empty node set. § notApplicable: this target was not even selected by the target XPath
expression, while being of the same general artifact type (e.g. message
type). |
Test Assertion: |
|
Description: |
The soap12:Envelope
contains @role with unspecified values. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[.//attribute::*:role] |
Predicate: |
every $rval in .//*/attribute::*:role satisfies ($rval = 'http://www.w3.org/2003/05/soap-envelope/role/next' or $rval = 'http://www.w3.org/2003/05/soap-envelope/role/none') |
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: § passed § failed § warning § notApplicable § notRelevant § missingInput § undetermined 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). 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: § mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT,
REQUIRED (and sometimes MAY NOT) § preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT
RECOMMENDED § permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: § @true attribute: may take values among {passed, failed, warning, undetermined}
(default is 'passed') § @false attribute: may take values among {passed, failed,
warning, undetermined} (default is 'failed') The reported outcomes
have the following meaning: § passed: the target passes the test and can be considered as fulfilling
the profile feature. § failed: the target fails the test and can be considered as violating
(or not exhibiting) the profile feature. § warning: the test result is inconclusive. There is a possibility of
profile requirement violation, that deserved further investigation. § undetermined: the test result is inconclusive for this predicate value. 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: § notRelevant: the target failed the prerequisite condition and therefore
does not qualify for further testing (i.e. the predicate expression is NOT
evaluated on it). § missingInput: a cotarget expression returned an empty node set. § notApplicable: this target was not even selected by the target XPath
expression, while being of the same general artifact type (e.g. message
type). |
Test Assertion: |
|
Description: |
The soap12:Envelope
contains a Fault with unspecified Detail content. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[soap12:Body/soap12:Fault/soap12:Detail] |
Predicate: |
fn:true() |
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: § passed § failed § warning § notApplicable § notRelevant § missingInput § undetermined 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). 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: § mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL, SHALL NOT,
REQUIRED (and sometimes MAY NOT) § preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT
RECOMMENDED § permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: § @true attribute: may take values among {passed, failed, warning, undetermined}
(default is 'passed') § @false attribute: may take values among {passed, failed,
warning, undetermined} (default is 'failed') The reported outcomes
have the following meaning: § passed: the target passes the test and can be considered as fulfilling
the profile feature. § failed: the target fails the test and can be considered as violating
(or not exhibiting) the profile feature. § warning: the test result is inconclusive. There is a possibility of
profile requirement violation, that deserved further investigation. § undetermined: the test result is inconclusive for this predicate value. 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: § notRelevant: the target failed the prerequisite condition and therefore
does not qualify for further testing (i.e. the predicate expression is NOT
evaluated on it). § missingInput: a cotarget expression returned an empty node set. § notApplicable: this target was not even selected by the target XPath
expression, while being of the same general artifact type (e.g. message
type). |
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 transmitting messages, the
envelope. The Profile places the following constraints on the use and
serialization of the soap12:Envelope element and its content:
This section of the Profile incorporates the following
specifications by reference:
R9701
(from issue: )
An ENVELOPE MUST be serialized as XML 1.0. TESTABLE BP1019
Test Assertion: |
|
Description: |
The soap12:Envelope in
the message is a well-formed XML 1.0 document. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope |
co-Target: metadata |
$target/../../wsil:messageContents[@validXml and @xmlVersion] |
Predicate: |
$target/../../wsil:messageContents[@validXml = fn:true() and @xmlVersion = '1.0'] |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
The soap12:Envelope
does not conform to XML 1.0. |
Diagnostic Data: |
{SOAP message}{any XML
parser error messages} |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: x4)
A RECEIVER MUST accept envelopes that include the Unicode Byte Order Mark
(BOM). C 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
(from issue: s5)
A RECEIVER MUST accept messages with envelopes that contain an XML
Declaration. C TESTABLE BP1015
Test Assertion: |
|
Description: |
A receiver must not
fault messages with envelopes that contain an XML Declaration. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents[@containsXmlDecl = 'true']/soap12:Envelope |
Predicate: |
not
(/wsil:testLog/wsil:messageLog/wsil:message[(@type = 'response' and
@conversation = $target/../../@conversation) or (.//soap12:Envelope/soap12:Header/wsa:RelatesTo[@RelationshipType
= 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] =
$target/soap12:Header/wsa:MessageID)]/wsil:messageContents/soap12:Envelope/soap12:Body/soap12:Fault
) |
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: |
{SOAP message} |
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). 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:
The reported outcomes
have the following meaning:
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.
R1012
(from issue: s22)
An ENVELOPE MUST be serialized using either UTF-8 or UTF-16 character
encoding. TESTABLE BP1018
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope |
Predicate: |
$target/../../wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'charset' and (fn:starts-with(fn:lower-case(@value), 'utf-8') or fn:starts-with(fn:lower-case(@value),'utf-16'))] or fn:starts-with(fn:lower-case($target/../wsil:messageContents/@encoding),'utf-8') or fn:starts-with(fn:lower-case($target/../wsil:messageContents/@encoding),'utf-16') |
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: |
Complete message. |
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). 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:
The reported outcomes have the following meaning:
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 (from issue: er088)
A SIMPLE_SOAP_MESSAGE MUST indicate the correct
character encoding, using the "charset" parameter. C 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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope |
Predicate: |
$target/../../wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'charset' and (fn:starts-with(fn:lower-case(@value), 'utf-8') or fn:starts-with(fn:lower-case(@value),'utf-16'))] or fn:starts-with(fn:lower-case($target/../wsil:messageContents/@encoding),'utf-8') or fn:starts-with(fn:lower-case($target/../wsil:messageContents/@encoding),'utf-16') |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: er023)
A RECEIVER MUST ignore the encoding pseudo-attribute of the envelope's XML
declaration. 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.
R1020
(from issue: bp120047)
A XOP_ENCODED_MESSAGE MUST include the start-info
parameter in the Content-Type
header of the enclosing multipart/related
MIME entity body. TESTABLE BP1020
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[wsil:httpHeaders/wsil:contentTypeHeader/@type = 'multipart' and wsil:httpHeaders/wsil:contentTypeHeader/@subtype = 'related' and wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'type']/@value= 'application/xop+xml'] |
Predicate: |
wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[fn:lower-case(@key) = 'start-info' and @value != ''] |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: bp120047)
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. TESTABLE BP1021
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[wsil:httpHeaders/wsil:contentTypeHeader/@type = 'multipart' and wsil:httpHeaders/wsil:contentTypeHeader/@subtype = 'related' and wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'type']/@value = 'application/xop+xml'] |
Predicate: |
some $rootContentID in string(wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'start']/@value) satisfies string(wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[fn:lower-case(@key) = 'start-info']/@value) = string(wsil:messageAttachments//*:mimeHeaders[ *:mimeHeader[@key = 'Content-ID' and @value = $rootContentID]]/wsil:contentTypeHeader/wsil:parameter[@key = 'type']/@value) |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: bp120047)
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. NOT_TESTABLE
R1023
(from issue: bp120047)
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. NOT_TESTABLE
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>
...
This section of the Profile incorporates the following
specifications by reference:
SOAP 1.2 defines a structure for composing messages, the envelope.
The Profile mandates the use of that structure, and places the following
constraints on its use:
R9980
(from issue: )
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). TESTABLE BP1600
Test Assertion: |
|
Description: |
The envelope conforms
to the structure specified in SOAP 1.2 Part 1, Section 5. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope
|
co-Target: metadata |
$target/../@schemaValid |
Predicate: |
$target/../@schemaValid
= fn:true() |
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: |
SOAP envelope. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: )
An ENVELOPE MUST have exactly zero or one child elements of the soap12:Body
element. TESTABLE BP1881
Test Assertion: |
|
Description: |
The envelope must have
exactly zero or one child elements of the soap12:Body |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope |
Predicate: |
count(soap12:Body/*) le 1 |
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: |
SOAP envelope. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: s37)
The children of the soap12:Body
element in an ENVELOPE MUST be namespace
qualified. TESTABLE BP1202
Test Assertion: |
|
Description: |
Each child element (if
any) of the soap12:Body element is namespace qualified (not the
grandchildren). |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[count(soap12:Body/*) > 0] |
Predicate: |
fn:namespace-uri-from-QName(fn:node-name(soap12:Body/*)) != '' |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
A child element of the
soap12:Body element is not namespace qualified. |
Diagnostic Data: |
SOAP envelope. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: s4)
An ENVELOPE MUST NOT contain a Document Type Declaration. C TESTABLE BP1007
Test Assertion: |
|
Description: |
DTDs relating to
soap12:Header or soap12:Body documents, are not present in the envelope: no
DOCTYPE element is present. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope |
co-Target: metadata |
$target/../@containsDTD |
Predicate: |
not(../@containsDTD = fn:true()) |
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: |
SOAP envelope. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: s4)
An ENVELOPE MUST NOT contain Processing Instructions. C TESTABLE BP1208
Test Assertion: |
|
Description: |
The SOAP envelope does
not include XML processing instructions. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope |
co-Target: metadata |
$target/../@containsProcessingInstructions |
Predicate: |
not(../@containsProcessingInstructions = fn:true()) |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
a SOAP envelope
contains XML processing instructions. |
Diagnostic Data: |
SOAP envelope. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: er032)
An ENVELOPE SHOULD NOT contain the namespace declaration
xmlns:xml="http://www.w3.org/XML/1998/namespace". C TESTABLE BP1033
Test Assertion: |
|
Description: |
The SOAP envelope does
not contain the namespace declaration
xmlns:xml="http://www.w3.org/XML/1998/namespace". |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope |
Predicate: |
not(.//*[fn:namespace-uri(.)
= 'http://www.w3.org/XML/1998/namespace']) |
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: |
SOAP envelope |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: sch1)
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). NOT_TESTABLE
R1032
(from issue: swa142)
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"
. TESTABLE BP1032
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope |
Predicate: |
every $attrib in
(self::node()/attribute::*, ./soap12:Header/attribute::*,
./soap12:Body/attribute::*) satisfies fn:namespace-uri($attrib) !=
'http://www.w3.org/2003/05/soap-envelope' and fn:namespace-uri($attrib) !=
'http://schemas.xmlsoap.org/soap/envelope/' |
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: |
SOAP envelope |
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). 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:
The reported outcomes
have the following meaning:
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 section of the Profile incorporates the following
specifications by reference:
SOAP 1.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
(from issue: s58 BP20131) 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. Whether or not the
fault is transmitted (and not just generated) will be goverened by R1030. NOT_TESTABLE
R1030
(from issue: s58)
A RECEIVER that generates a fault SHOULD notify the end user that a fault
has been generated when practical, by whatever means is deemed appropriate to
the circumstance. NOT_TESTED
Note that there may be valid reasons (such as
security considerations) why a fault may 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
(from issue: s6)
A RECEIVER MUST interpret a SOAP message as a Fault when the soap12:Body
of the message has a single soap12:Fault
child. NOT_TESTABLE
This section of the Profile incorporates the following
specifications by reference:
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.
SOAP 1.2 defines a single protocol binding, for HTTP. The Profile
makes use of that binding, and places the following constraints on its use:
Several versions of HTTP are defined.
HTTP/1.1 has performance advantages, and is more clearly specified than
HTTP/1.0.
R1141
(from issue: h8)
When HTTP is used as the
transport, a MESSAGE MUST be sent using either
HTTP/1.1 or HTTP/1.0. TESTABLE BP1002
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request'] |
Predicate: |
fn:contains(wsil:httpHeaders/wsil:requestLine/text(),
'HTTP/1.0') or fn:contains(wsil:httpHeaders/wsil:requestLine/text(),
'HTTP/1.1') |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
The message is not
sent using HTTP/1.1 or HTTP/1.0. |
Diagnostic Data: |
All HTTP headers. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: h8)
When HTTP is used as, a MESSAGE SHOULD be sent using HTTP/1.1. TESTABLE BP1001
Test Assertion: |
|
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: |
//message |
Prerequisite: |
BP1002 |
Predicate: |
contains(wsil:httpHeaders/requestLine/text(), 'HTTP/1.1') |
Reporting: |
true=passed,
false=failed |
Prescription: |
preferred |
Error Message: |
The message is not
sent using HTTP/1.1. |
Diagnostic Data: |
All HTTP headers. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: s2 BP20146) 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. C TESTABLE BP1006
Test Assertion: |
|
Description: |
The SOAPAction header
contains a quoted string of any value, including "". |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request'][wsil:httpHeaders/wsil:contentTypeHeader] |
Predicate: |
every $par in wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter satisfies not($par/@quoted) or not($par/@key eq 'type' or fn:lower-case($par/@key) eq 'start-info' or $par/@key eq 'action' or $par/@key eq 'boundary') or $par/@quoted = fn:true() |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
SOAPAction HTTP header
does not contain a quoted string. |
Diagnostic Data: |
All HTTP headers. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: s2 BP20146) 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. C NOT_TESTED
R1127
(from issue: swa88)
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. NOT_TESTABLE
CORRECT:
A WSDL Description that
has:
<wsoap12:operation
soapAction="http://example.org/foo"/>
results in a message with
an action parameter on the Content-Type MIME header field-value set to:
"http://example.org/foo"
CORRECT:
A WSDL Description that
has:
<wsoap12:operation/>
or
<wsoap12:operation
soapAction=""/>
must not result in a
message with an action parameter on the Content-Type MIME header field-value.
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
(from issue: s15)
An INSTANCE MUST use a 2xx HTTP status code on a response message that
indicates the successful outcome of a HTTP Request. NOT_TESTABLE
R1111
(from issue: s15)
An INSTANCE SHOULD use a "200 OK" HTTP status code on a response
message that contains an envelope that is not a fault. TESTABLE BP1100
Test Assertion: |
|
Description: |
The message uses a
"200 OK" HTTP status code. |
Target: |
//wsil:message[@type='response'][wsil:messageContents/soap12:Envelope/soap12:Body[not(soap12:Fault)]] |
Predicate: |
contains(wsil:httpHeaders/wsil:requestLine, "200 OK") |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: s15)
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. TESTABLE BP1101
Test Assertion: |
|
Description: |
The response message,
if successfully processed at HTTP level, is sent using either a "200
OK" or "202 Accepted" HTTP status code. |
Target: |
//wsil:message[@type='response'][wsil:messageContents[not(soap12:Envelope)]][not (matches(wsil:httpHeaders/wsil:requestLine, "4[0-9][0-9]"))] |
Predicate: |
contains(wsil:httpHeaders/wsil:requestLine, "200 OK") or contains(wsil:httpHeaders/wsil:requestLine, "202 Accepted") |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: h5)
An INSTANCE MUST use the "307 Temporary Redirect" HTTP status code
when redirecting a request to a different endpoint. NOT_TESTABLE
R1131
(from issue: h5)
A CONSUMER MAY automatically redirect a request when it encounters a
"307 Temporary Redirect" HTTP status code in a response. 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
(from issue: h4)
An INSTANCE MAY use the HTTP state mechanism ("Cookies"). NOT_TESTED
R1122
(from issue: h4)
An INSTANCE using Cookies SHOULD conform to RFC2965. NOT_TESTED
R1121
(from issue: h4)
An INSTANCE SHOULD NOT require consumer support for Cookies in order to
function correctly. NOT_TESTED
R1123
(from issue: )
The value of the cookie
MUST be considered to be opaque by the CONSUMER. 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.
R1125
(from issue: BP20142)
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. TESTABLE
R1126
(from issue: BP20142)
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. TESTABLE
R1128
(from issue: BP20142)
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. TESTABLE
R1129
(from issue: BP20142)
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. 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 uses URIs as identifiers. For example, the role
attribute value is a URI that identify the SOAP node to which a
particular header block is targeted. 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", in SOAP
1.2, is a simple formatted string.
R1160
(from issue: bp20006)
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 strings (see RFC3986). 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
(from issue: BP20028)
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. NOT_TESTED
R1041
(from issue: BP20028)
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. 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
(from issue: bp12022)
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. C TESTABLE BP1142a BP1142b BP1142c BP1143a BP1143b BP1143c
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request']/wsil:messageContents/soap12:Envelope [soap12:Header[ wsa:Action
and not (wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply'
or not (@RelationshipType)] )] and soap12:Body/* and not
(soap12:Body/soap12:Fault) ] [ some $myenv in . satisfies some $message in
//wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding
[.//wsoap12:*[@style = 'rpc']]/wsdl:operation[@name =
fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))] |
Predicate: |
( if |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'response']/wsil:messageContents/ soap12:Envelope[soap12:Header[wsa:Action]
and soap12:Body/* and not (soap12:Body/soap12:Fault)] [ some $myenv in .
satisfies some $message in //wsdl:definitions/wsdl:message satisfies
($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:*[@style
= 'rpc']]/ wsdl:operation [fn:string-join((@name, 'Response' ),'' ) =
fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))] |
co-Target: related-Request |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request']/
wsil:messageContents/soap12:Envelope[soap12:Header/wsa:MessageID =
$target/soap12:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply'
or not (@RelationshipType)] ] |
Predicate: |
( not
($related-Request/soap12:Header/wsa:ReplyTo) or
($related-Request/soap12:Header/wsa:ReplyTo/wsa:Address='http://www.w3.org/2005/08/addressing/anonymous'
) ) and ( $target/soap12:Header/wsa:RelatesTo [ not ( @RelationshipType ) or
(@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] ) and (
$target/soap12:Header[ not (wsa:To) or (wsa:To =
'http://www.w3.org/2005/08/addressing/anonymous' )] ) and (: correct
wsa:Action value :) (some $opmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/
wsdl:operation[ $myOpBinding/@name = @name ]/wsdl:output 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,
'Response' ),'' ) ),'/' ) ) ) ) |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request']/wsil:messageContents/ soap12:Envelope [soap12:Body[not
(soap12:Fault)] and soap12:Header [wsa:Action and (wsa:RelatesTo
[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]
) ] ] [ some $myenv in . satisfies some $message in
//wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:*[@style
= 'rpc']]/ wsdl:operation [fn:string-join((@name, 'Response' ),'' ) =
fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))] |
co-Target: related-Request |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request']/ wsil:messageContents/soap12:Envelope[soap12:Header/wsa:MessageID
= $target/soap12:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ] |
Predicate: |
(
($related-Request/soap12:Header/wsa:ReplyTo) and not
($related-Request/soap12:Header/wsa:ReplyTo/wsa:Address='http://www.w3.org/2005/08/addressing/anonymous'
) ) and ( $target/soap12:Header/wsa:RelatesTo [ not ( @RelationshipType ) or
(@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] ) and (
$target/soap12:Header[ (wsa:To) and not (wsa:To =
'http://www.w3.org/2005/08/addressing/anonymous' ) ] ) and (: correct
wsa:Action value :) (some $opmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/
wsdl:operation[ $myOpBinding/@name = @name ]/wsdl:output 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,
'Response' ),'' ) ),'/' ) ) ) ) |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request']/wsil:messageContents/ soap12:Envelope [soap12:Body[not
(soap12:Fault)] and soap12:Header [wsa:Action and not (wsa:RelatesTo [@RelationshipType
= 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] )
] ] [ some $myenv in . satisfies ( every $message in
//wsdl:definitions/wsdl:message satisfies ( (not($message/wsdl:part[1]/@type)
) and ( $myenv/soap12:Body/*[1] or $myenv/soap12:Header/wsa:Action )) ) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation
[ some $opBinding in . satisfies (if ($target/soap12:Body/*[1] ) then (some
$dmesg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element),
. ) = fn:node-name($target/soap12:Body/*[1])] ] satisfies some $dopmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:input
[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) =
$dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ) else fn:true()
) and ( if ($target/soap12:Header/wsa:Action) then ( some $opmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/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' ),'' ) ),'/' ) ) ) and ( $opBinding/@name = $opmsg/../@name ) )
else fn:true() ) ] |
Predicate: |
( if ( /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() ) |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'response']/wsil:messageContents/soap12:Envelope [soap12:Body[not
(soap12:Fault) ] and soap12:Header[wsa:Action] ] [ some $myenv in . satisfies
( every $message in //wsdl:definitions/wsdl:message satisfies (
(not($message/wsdl:part[1]/@type) ) and ( $myenv/soap12:Body/*[1] or
$myenv/soap12:Header/wsa:Action )) ) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation
[ some $opBinding in . satisfies (if ($target/soap12:Body/*[1] ) then (some
$dmesg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element),
. ) = fn:node-name($target/soap12:Body/*[1])] ] satisfies some $dopmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output
[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) =
$dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ) else fn:true()
) (: and ( if ($target/soap12:Header/wsa:Action) then ( some $opmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output
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, 'Response' ),'' )
),'/' ) ) ) and ( $opBinding/@name = $opmsg/../@name ) ) else fn:true() ) :)
] |
co-Target: related-Request |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request']/
wsil:messageContents/soap12:Envelope[soap12:Header/wsa:MessageID =
$target/soap12:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ] |
Predicate: |
( not
($related-Request/soap12:Header/wsa:ReplyTo) or
($related-Request/soap12:Header/wsa:ReplyTo/wsa:Address='http://www.w3.org/2005/08/addressing/anonymous'
) ) and ( $target/soap12:Header/wsa:RelatesTo [ not ( @RelationshipType ) or
(@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] ) and (
$target/soap12:Header[ not (wsa:To) or (wsa:To =
'http://www.w3.org/2005/08/addressing/anonymous' )] ) |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request']/wsil:messageContents/soap12:Envelope [soap12:Body[not
(soap12:Fault)] and soap12:Header [wsa:Action and (wsa:RelatesTo
[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] ) ] ] [ some $myenv in . satisfies ( every $message in
//wsdl:definitions/wsdl:message satisfies ( (not($message/wsdl:part[1]/@type)
) and ( $myenv/soap12:Body/*[1] or $myenv/soap12:Header/wsa:Action )) ) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation
[ some $opBinding in . satisfies (if ($target/soap12:Body/*[1] ) then (some
$dmesg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element),
. ) = fn:node-name($target/soap12:Body/*[1])] ] satisfies some $dopmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output
[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) =
$dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ) else fn:true()
) and ( if ($target/soap12:Header/wsa:Action) then ( some $opmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output
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, 'Response' ),'' )
),'/' ) ) ) and ( $opBinding/@name = $opmsg/../@name ) ) else fn:true() ) ] |
co-Target: related-Request |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'request']/ wsil:messageContents/soap12:Envelope[soap12:Header/wsa:MessageID
= $target/soap12:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] ] |
Predicate: |
(
($related-Request/soap12:Header/wsa:ReplyTo) and not
($related-Request/soap12:Header/wsa:ReplyTo/wsa:Address='http://www.w3.org/2005/08/addressing/anonymous'
) ) and ( $target/soap12:Header/wsa:RelatesTo [ not ( @RelationshipType ) or
(@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] ) and (
$target/soap12:Header[ (wsa:To) and not (wsa:To =
'http://www.w3.org/2005/08/addressing/anonymous' )] ) |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: bp12027)
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. TESTABLE BP1144
Test Assertion: |
|
Description: |
The message must
specify a SOAPAction 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: |
/wsil:testLog/wsil:messageLog/wsil:message[wsil:messageContents/soap12:Envelope/soap12:Header/wsa:Action]
|
Predicate: |
(messageContents/soap12:Envelope/soap12:Header/wsa:Action/text() = wsil:httpHeaders/wsil:httpHeader[@key = 'SOAPAction']/@value) or not(wsil:httpHeaders/wsil:httpHeader[@key = 'action']) |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
A message did not
specify a SOAPAction 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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: bp12009)
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. TESTABLE BP1035
Test Assertion: |
|
Description: |
The value of the
wsa:Action element is http://www.w3.org/2005/08/addressing/soap/fault |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[soap12:Header/wsa:Action and (fn:ends-with(soap12:Body/soap12:Fault/soap12:Code/soap12:Value,'MustUnderstand') or fn:ends-with(soap12:Body/soap12:Fault/soap12:Code/soap12:Value, 'VersionMismatch'))] |
Predicate: |
normalize-space(string(./soap12:Header/wsa:Action)) eq 'http://www.w3.org/2005/08/addressing/soap/fault' |
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: |
Complete message. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: bp12026)
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. C Compat 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
(from issue: BP20121 BP20126) 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). 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
(from issue: BP20121 BP20126) A RECEIVER MUST transmit non-faulting responses to the [reply endpoint] MAP
or generate a fault instead (per R1029.) TESTABLE BP1146
Test Assertion: |
|
Description: |
A non-faulting
response must be sent to the [reply endpoint] MAP or generate a fault
instead. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
[ (@type = 'response' and (some $resp in . satisfies some $req in
/wsil:testLog/wsil:messageLog/wsil:message[@type = 'request' and
@conversation = $resp/@conversation] satisfies $req//wsa:* ) ) or
./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] ]
[wsil:messageContents/soap12:Envelope[not(soap12:Body/soap12:Fault)]] |
co-Target: myRequestMsg |
/wsil:testLog/wsil:messageLog/wsil:message
[(@type = 'request' and @conversation = $target/@conversation) or
(./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:MessageID = $target/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] ) ] |
Predicate: |
((not($myRequestMsg/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:ReplyTo)
or
$myRequestMsg/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:ReplyTo/wsa:Address
= 'http://www.w3.org/2005/08/addressing/anonymous') and $target[@type =
'response']/wsil:messageContents/soap12:Envelope/soap12:Header [ wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous'
or not(wsa:To )]) or (
$target/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:To =
$myRequestMsg/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:ReplyTo/wsa:Address
) |
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: |
Complete message |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: BP12006)
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). 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
(from issue: BP20121 BP20126 BP20150) If a fault
is generated, the RECEIVER SHOULD transmit the fault
(per R1029). NOT_TESTED
R1161
(from issue: BP20150)
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. TESTABLE
R1162
(from issue: BP20150)
When the [fault endpoint]
MAP exists, the RECEIVER MUST NOT transmit faults
to the [reply endpoint] MAP. TESTABLE
R1148
(from issue: BP20121 BP20126) 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). 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
(from issue: BP20157)
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. 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
(from issue: BP20121 BP20126) If any WS-Addressing MAPs
are not honored, the RECEIVER MUST generate a fault. 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
(from issue: BP20121 BP20126) 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. TESTABLE BP1152a BP1152b
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message
[wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo[@RelationshipType
= 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]
and (some $req in /wsil:testLog/wsil:messageLog/wsil:message satisfies
$req/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:MessageID =
wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] and
$req/wsil:messageContents/soap12:Envelope/soap12:Header[wsa:ReplyTo[1]/wsa:Address
ne 'http://www.w3.org/2005/08/addressing/anonymous'] )] |
co-Target: myRequestMsg |
/wsil:testLog/wsil:messageLog/wsil:message
[wsil:messageContents/soap12:Envelope/soap12:Header/wsa:MessageID =
$target/wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo [@RelationshipType
= 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]] |
Predicate: |
($target/@type =
'request') and ( $target/wsil:messageContents/soap12:Envelope/soap12:Header [
(wsa:To) and not (wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' )
] ) |
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: |
Complete message |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[wsil:messageContents/soap12:Envelope
[(wsa:To) and not (wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous'
) ]] |
Predicate: |
$target/@type = 'request' |
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: |
Complete message |
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). 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:
The reported outcomes
have the following meaning:
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 proposal makes the following, clarifying requirement.
R1153
(from issue: BP20129 20148) 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. TESTABLE
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:
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
(from issue: BP20129 BP20148) 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. 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
(from issue: BP20129 BP20148) 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. 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
(from issue: BP20133)
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
. NOT_TESTABLE_XPATH
R1157
(from issue: BP20133)
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. 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.
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.
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.
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
(from issue: BP20154)
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. 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
(from issue: u12)
Either an INSTANCE's WSDL 1.1 description, its UDDI binding template, or both MUST
be available to an authorized consumer upon request. TESTABLE BP2703
Test Assertion: |
|
Description: |
The wsdl:definitions
is a well-formed XML 1.0 document. The wsdl:definitions namespace has value:
http://schemas.xmlsoap.org/wsdl/. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[fn:prefix-from-QName(fn:node-name(*:definitions)) eq 'wsdl' or wsdl:definitions] |
Predicate: |
fn:namespace-uri-from-QName(fn:node-name(./*:definitions)) eq 'http://schemas.xmlsoap.org/wsdl/' or ./*:bindingTemplate |
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: |
Error message from the
XML parser |
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). 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:
The reported outcomes
have the following meaning:
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.
This section of the Profile incorporates the following
specifications by reference:
WSDL 1.1 defines an XML-based structure 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
(from issue: )
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". TESTABLE BP2705
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[wsdl:definitions]
|
co-Target: metadata |
$target/@schemaValid |
Predicate: |
$target/@schemaValid =
fn:true() |
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: |
Error message from the
XML parser |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: BP20155)
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". TESTABLE BP2704
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[.//wsoap12:*]
|
co-Target: metadata |
$target/../@schemaValid |
Predicate: |
$target/../@schemaValid
= fn:true() |
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: |
Error message from the
XML parser |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w10)
A DESCRIPTION MUST only use the WSDL "import" statement to import
another WSDL description. TESTABLE BP2101
Test Assertion: |
|
Description: |
Each wsdl:import statement is only used to import another WSDL
description. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:import]
|
Predicate: |
every $wsdlImp in $target/wsdl:import satisfies some $wsdlFile
in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[@filename=$wsdlImp/@location]
satisfies ( (fn:namespace-uri($wsdlFile/*[1]) =
'http://schemas.xmlsoap.org/wsdl/' ) and ( fn:local-name($wsdlFile/*[1]) =
'definitions' ) ) |
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
A wsdl:import element does not contain a reference to another
WSDL description. |
Diagnostic Data: |
wsdl:import element(s) that does not reference a WSDL
description. |
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). 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:
The reported outcomes have the following meaning:
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 (from issue: swa135)
In a DESCRIPTION, the namespace attribute
of the wsdl:import
MUST NOT be a relative
URI. TESTABLE BP2803
Test Assertion: |
|
Description: |
The "namespace" attribute's value is not a relative
URI. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:import] |
Prerequisite: |
BP2703 |
Predicate: |
every $imp in wsdl:import[@namespace] satisfies (starts-with($imp/@namespace, 'http://') or starts-with($imp/@namespace, 'HTTP://') or starts-with($imp/@namespace, 'urn:') or starts-with($imp/@namespace, 'URN:') or starts-with($imp/@namespace, 'ft') or starts-with($imp/@namespace, 'FT')) |
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
The wsdl:import element's "namespace" attribute value
is a relative URI. |
Diagnostic Data: |
Defective wsdl:import element. |
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). 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:
The reported outcomes have the following meaning:
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 (from issue: w10)
To import XML Schema Definitions, a DESCRIPTION MUST use the XML Schema "import" statement. TESTABLE BP2101
Test Assertion: |
BP2101 |
Description: |
Each wsdl:import
statement is only used to import another WSDL description. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:import]
|
Predicate: |
every $wsdlImp in
$target/wsdl:import satisfies some $wsdlFile in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[@filename=$wsdlImp/@location]
satisfies ( (fn:namespace-uri($wsdlFile/*[1]) =
'http://schemas.xmlsoap.org/wsdl/' ) and ( fn:local-name($wsdlFile/*[1]) =
'definitions' ) ) |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
A wsdl:import element
does not contain a reference to another WSDL description. |
Diagnostic Data: |
wsdl:import element(s)
that does not reference a WSDL description. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w10)
A DESCRIPTION MUST use the XML Schema "import" statement only within
the xsd:schema
element of the types section. TESTABLE BP2103
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[descendant::xsd:import] |
Predicate: |
every $imp in descendant::xsd:import satisfies ($imp/ancestor::xsd:schema and $imp/ancestor::wsdl:types) |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
A XML schema import
element was found outside of an xsd:schema element. |
Diagnostic Data: |
Defective XML schema
import element. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w10)
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". TESTABLE BP2106
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:types/xsd:schema/xsd:import]
|
Predicate: |
every $schemaImp in
$target/wsdl:types/xsd:schema/xsd:import[@schemaLocation] satisfies some
$impSchemaFile in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[@filename=$schemaImp/@schemaLocation]
satisfies ( fn:namespace-uri($impSchemaFile/*[1])='http://www.w3.org/2001/XMLSchema'
and fn:local-name($impSchemaFile/*[1])='schema' ) |
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: |
Defective XML schema
import element. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: er055)
An XML Schema directly or
indirectly imported by a DESCRIPTION MAY include the Unicode
Byte Order Mark (BOM). NOT_TESTED
R2010
(from issue: er055)
An XML Schema directly or
indirectly imported by a DESCRIPTION MUST use either UTF-8 or
UTF-16 encoding. TESTABLE BP2202
Test Assertion: |
|
Description: |
All imported schema
use UTF-8 or UTF-16 for the encoding. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:types/xsd:schema/xsd:import]
|
Predicate: |
every $schImp in
$target/wsdl:types/xsd:schema/xsd:import[@schemaLocation] satisfies ( some
$schFile in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[@filename=$schImp/@schemaLocation]
satisfies (not ($schFile/@encoding) or $schFile/@encoding = 'UTF-8' or
$schFile/@encoding = 'UTF-16' or $schFile/@encoding = 'utf-8' or
$schFile/@encoding = 'utf-16') ) |
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: |
XML declaration statement. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: er055)
An XML Schema directly or
indirectly imported by a DESCRIPTION MUST use version 1.0 of
the eXtensible Markup Language W3C Recommendation. NOT_TESTABLE
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
(from issue: w29)
A DESCRIPTION MUST specify a non-empty location
attribute on the wsdl:import
element. TESTABLE BP2098
Test Assertion: |
|
Description: |
The
"location" attribute is specified for the wsdl:import element, and
has a non-empty value. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:import |
Predicate: |
@location and
@location != '' |
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: |
Defective wsdl:import element. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w29)
A CONSUMER MAY, but need
not, retrieve a WSDL description from the URI specified in the location
attribute on a wsdl:import
element. C 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
(from issue: )
When they appear in a DESCRIPTION, wsdl:import
elements MUST precede all other elements from the WSDL namespace
except wsdl:documentation
. TESTABLE BP2105
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:import]
|
Predicate: |
not(wsdl:import/preceding-sibling::wsdl:*[(local-name-from-QName(node-name(.))
!= 'documentation') and (local-name-from-QName(node-name(.)) != 'import')]) |
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: |
Display the WSDL
import element(s) that failed the assertion. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: )
When they appear in a DESCRIPTION, wsdl:types
elements MUST precede all other elements from the WSDL namespace
except wsdl:documentation
and wsdl:import
. TESTABLE BP2018
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:types]
|
Prerequisite: |
BP2703 |
Predicate: |
not(wsdl:types/preceding-sibling::wsdl:*[(local-name-from-QName(node-name(.))
!= 'documentation') and (local-name-from-QName(node-name(.)) != 'import') and
(local-name-from-QName(node-name(.)) != 'types')]) |
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). 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:
The reported outcomes
have the following meaning:
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:
|
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
(from issue: )
A DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C
Recommendation. TESTABLE BP2700
Test Assertion: |
|
Description: |
The wsdl:definitions
is a well-formed XML 1.0 document. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions |
co-Target: metadata |
$target/../@validXml |
Predicate: |
../@validXml=fn:true() |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
The wsdl:definitions
is not a well-formed XML 1.0 document. |
Diagnostic Data: |
Error message from the
XML parser |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: swa101)
A DESCRIPTION SHOULD NOT contain the namespace declaration
xmlns:xml="http://www.w3.org/XML/1998/namespace". C TESTABLE BP2034
Test Assertion: |
|
Description: |
The candidate
description does not contain the namespace declaration
xmlns:xml="http://www.w3.org/XML/1998/namespace". |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions
|
Prerequisite: |
BP2703 |
Predicate: |
not(descendant-or-self::*/namespace::node()[1] = 'xmlns:xml="http://www.w3.org/XML/1998/namespace"') |
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). 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:
The reported outcomes
have the following meaning:
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 documents that use the UTF-8
character encoding to include a BOM; therefore, description processors must be
prepared to accept them.
R4002
(from issue: x4)
A DESCRIPTION MAY include the Unicode Byte Order Mark (BOM). C NOT_TESTED
The Profile consistently requires either
UTF-8 or UTF-16 encoding for both SOAP and WSDL.
R4003
(from issue: w40)
A DESCRIPTION MUST use either UTF-8 or UTF-16 encoding. TESTABLE BP2201
Test Assertion: |
|
Description: |
The XML declaration
statement uses UTF-8 or UTF-16 for the encoding. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions
|
co-Target: metadata |
$target/../@encoding |
Predicate: |
fn:starts-with(fn:lower-case(../@encoding),
'utf-8') or fn:starts-with(fn:lower-case(../@encoding), 'utf-16') |
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: |
XML declaration statement. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w26)
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. TESTABLE BP2104
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:import |
Prerequisite: |
BP2101 |
Predicate: |
some $wimp in .
satisfies some $descFile in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile[fn:ends-with($wimp/@location,
@filename)] satisfies ($descFile/wsdl:definitions/@targetNamespace =
$wimp/@namespace) |
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: |
wsdl:import element. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: swa093)
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. WSDL20 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
(from issue: )
A DESCRIPTION containing WSDL extensions MUST NOT use them to contradict other
requirements of the Profile. NOT_TESTABLE
R2026
(from issue: )
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. TESTABLE BP2123
Test Assertion: |
|
Description: |
Contained WSDL
extension elements do not use the wsdl:required attribute value of
"true". |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/descendant::* [namespace-uri(.) != 'http://schemas.xmlsoap.org/wsdl/' and not(namespace-uri(.) = 'http://schemas.xmlsoap.org/wsdl/soap/' and (local-name(.) = 'binding' or local-name(.) = 'operation' or local-name(.) = 'body' or local-name(.) = 'header' or local-name(.) = 'headerfault' or local-name(.) = 'fault' or local-name(.) = 'address')) and (./ancestor::wsdl:portType or ./ancestor::wsdl:binding or ./ancestor::wsdl:message or ./ancestor::wsdl:types or ./ancestor::wsdl:import)] |
Predicate: |
not(@wsdl:required = fn:true() |
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: |
Display the extension
element that failed the assertion. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: )
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. 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
This section of the Profile incorporates the following
specifications by reference:
The wsdl:types
element of WSDL 1.1 encloses 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
(from issue: w10)
A DESCRIPTION MUST NOT use QName references to WSDL components in namespaces
that have been neither imported, nor defined in the referring WSDL document. TESTABLE BP2416
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions |
Predicate: |
(every $qref in $target/wsdl:service/wsdl:port/@binding
satisfies ( some $ns in fn:namespace-uri-from-QName(fn:resolve-QName
(xsd:string($qref),$qref/..) ) satisfies ( ($target/@targetNamespace = $ns )
or (some $wimp in $target/wsdl:import satisfies $wimp/@namespace = $ns ) ) )
) and (every $qref in $target/wsdl:binding/@type satisfies ( some $ns in
fn:namespace-uri-from-QName(fn:resolve-QName (xsd:string($qref),$qref/..) )
satisfies ( ($target/@targetNamespace = $ns ) or (some $wimp in
$target/wsdl:import satisfies $wimp/@namespace = $ns ) ) ) ) and (every $qref
in $target/wsdl:portType/wsdl:operation/wsdl:input/@message satisfies ( some
$ns in fn:namespace-uri-from-QName(fn:resolve-QName
(xsd:string($qref),$qref/..) ) satisfies ( ($target/@targetNamespace = $ns )
or (some $wimp in $target/wsdl:import satisfies $wimp/@namespace = $ns ) ) )
) and (every $qref in
$target/wsdl:portType/wsdl:operation/wsdl:output/@message satisfies ( some
$ns in fn:namespace-uri-from-QName(fn:resolve-QName
(xsd:string($qref),$qref/..) ) satisfies ( ($target/@targetNamespace = $ns )
or (some $wimp in $target/wsdl:import satisfies $wimp/@namespace = $ns ) ) )
) and (every $qref in
$target/wsdl:portType/wsdl:operation/wsdl:fault/@message satisfies ( some $ns
in fn:namespace-uri-from-QName(fn:resolve-QName (xsd:string($qref),$qref/..)
) satisfies ( ($target/@targetNamespace = $ns ) or (some $wimp in
$target/wsdl:import satisfies $wimp/@namespace = $ns ) ) ) ) and (every $qref
in $target/wsdl:binding/wsdl:operation/wsdl:*/wsoap12:header/@message satisfies
( some $ns in fn:namespace-uri-from-QName(fn:resolve-QName
(xsd:string($qref),$qref/..) ) satisfies ( ($target/@targetNamespace = $ns )
or (some $wimp in $target/wsdl:import satisfies $wimp/@namespace = $ns ) ) )
) and (every $qref in $target/wsdl:binding/wsdl:operation/wsdl:*/wsoap12:headerfault/@message
satisfies ( some $ns in fn:namespace-uri-from-QName(fn:resolve-QName
(xsd:string($qref),$qref/..) ) satisfies ( ($target/@targetNamespace = $ns )
or (some $wimp in $target/wsdl:import satisfies $wimp/@namespace = $ns ) ) )
) |
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: |
Defective QName(s). |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: er053)
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. TESTABLE BP2417
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions |
Predicate: |
(every $qref in
$target/wsdl:message/wsdl:part/@element satisfies ( some $ns in
fn:namespace-uri-from-QName(fn:resolve-QName (xsd:string($qref),$qref/..) )
satisfies ( ($target/wsdl:types/xsd:schema/@targetNamespace = $ns ) or (some
$simp in $target/wsdl:types/xsd:schema/xsd:import satisfies $simp/@namespace
= $ns ) ) ) ) and (every $qref in $target/wsdl:message/wsdl:part/@type
satisfies ( some $ns in fn:namespace-uri-from-QName(fn:resolve-QName
(xsd:string($qref),$qref/..) ) satisfies ( ($target/@targetNamespace = $ns )
or (some $simp in $target/wsdl:types/xsd:schema/xsd:import satisfies
$simp/@namespace = $ns ) or ($ns = 'http://www.w3.org/2001/XMLSchema' ) ) ) )
|
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: |
Defective QName(s). |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w43)
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). TESTABLE BP2107
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:types/xsd:schema]
|
Predicate: |
wsdl:types/xsd:schema[@targetNamespace != '' or (count(xsd:import) + count(xsd:annotation)) = count(child::*)] |
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: |
Defective xsd:schema
element(s). |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w30)
In a DESCRIPTION, declarations MUST NOT extend or restrict the soapenc:Array
type. TESTABLE BP2108b
Test Assertion: |
|
Description: |
The type soapenc:Array
does not appear in these declarations, and the wsdl:arrayType attribute is
not used in the type declaration. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:types[xsd:schema]
|
Predicate: |
not (xsd:schema[descendant::xsd:extension/@base = "soapenc:Array" or descendant::xsd:restriction/@base = "soapenc:Array"]) |
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: |
Defective declaration(s). |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w30)
In a DESCRIPTION, declarations MUST NOT use wsdl:arrayType
attribute in the type declaration. TESTABLE BP2108a
Test Assertion: |
|
Description: |
The type soapenc:Array
does not appear in these declarations, and the wsdl:arrayType attribute is
not used in the type declaration. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:types[xsd:schema] |
Predicate: |
not (xsd:schema/descendant::*/@wsdl:arrayType) |
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: |
Defective declaration(s). |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w30)
In a DESCRIPTION, elements SHOULD NOT be named using the convention ArrayOfXXX. TESTABLE BP2110
Test Assertion: |
|
Description: |
The declaration does
not use the naming convention ArrayOfXXX. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions[wsdl:types/xsd:schema]
|
Predicate: |
not (wsdl:types/xsd:schema/descendant::xsd:element[fn:starts-with(@name, 'ArrayOf')]) |
Reporting: |
true=passed,
false=failed |
Prescription: |
preferred |
Error Message: |
A declaration is using
the convention ArrayOfXXX. |
Diagnostic Data: |
Defective declaration(s). |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w30)
An ENVELOPE MUST NOT include the soapenc:arrayType
attribute. TESTABLE BP1204
Test Assertion: |
|
Description: |
The soap12:Body of the
envelope does not contain the soapenc:arrayType attribute. |
Target: |
//soap12:Envelope |
Predicate: |
not (descendant::*[@soapenc:arrayType]) |
Reporting: |
true=passed,
false=failed |
Prescription: |
mandatory |
Error Message: |
The soap12:Body of an
envelope contains the soapenc:arrayType attribute. |
Diagnostic Data: |
SOAP envelope. |
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). 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:
The reported outcomes
have the following meaning:
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:
|
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
(from issue: )
The target namespace for
WSDL definitions and the target namespace for schema definitions in a DESCRIPTION MAY be the same. WSDL20 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
(from issue: bp12002)
A DESCRIPTION SHOULD NOT contain multiple global element declarations that
share the same qualified name. TESTABLE BP2124
Test Assertion: |
|
Description: |
No two global element
declarations share the same qualified name. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:types/xsd:schema
|
Predicate: |
count (xsd:element[@name = preceding-sibling::element/@name]) = 0 |
Reporting: |
true=passed,
false=failed |
Prescription: |
preferred |
Error Message: |
Two or more global
element declarations share the same qualified name. |
Diagnostic Data: |
The wsdl:operation
elements containing the repeated global element declarations. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: bp12002)
A DESCRIPTION SHOULD NOT contain multiple type definitions that share the same
qualified name. TESTABLE BP2125
Test Assertion: |
|
Description: |
No two type
definitions share the same qualified name. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:types/xsd:schema
|
Predicate: |
(count (xsd:ComplexType[@name = preceding-sibling::ComplexType/@name]) = 0) and (count (xsd:SimpleType[@name = preceding-sibling::SimpleType/@name]) = 0) |
Reporting: |
true=passed,
false=failed |
Prescription: |
preferred |
Error Message: |
Two or more type
definitions share the same qualified name. |
Diagnostic Data: |
The elements
containing the repeated qualified name. |
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). 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:
The reported outcomes
have the following meaning:
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 section of the Profile incorporates the following
specifications by reference:
In WSDL 1.1, wsdl:message
elements 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; or style
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; or style
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"; or style
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
(from issue: w1, w17, w35.1) 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. TESTABLE BP2111
Test Assertion: |
|
Description: |
If the
"parts" attribute is present, then the wsoap12:body element(s) have
at most one part listed in the parts attribute. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[not(.//wsoap12:*[@style
= 'rpc'])] |
Prerequisite: |
BP2017 |
Predicate: |
not(.//wsoap12:body[@parts and contains(@parts," ")]) |
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: |
Defective wsoap12:body
element(s). |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w1, w17, w35.1) 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. TESTABLE BP2119
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[not(.//wsoap12:*[@style
= 'rpc'])] |
Prerequisite: |
BP2017 |
Predicate: |
every $sbody in wsdl:operation//wsoap12:body[not(@parts)]
satisfies some $msgname in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name
= $sbody/../../@name]/*[local-name(.) = local-name($sbody/..)]/@message satisfies
count(/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name
= $msgname]/wsdl:part) le 1 |
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: |
Defective wsdl:binding element. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w1)
A wsdl:binding
in a DESCRIPTION MAY contain wsoap12:body
element(s) that specify that zero parts from the soap12:Body
. NOT_TESTED
R2203
(from issue: w1, w35.2)
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. TESTABLE BP2013
Test Assertion: |
|
Description: |
The binding (in
wsoap12:body elements) only refers to part elements that have been defined
using the "type" attribute |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:*[@style = 'rpc']] |
Prerequisite: |
BP2017 |
Predicate: |
every $sbody in
wsdl:operation//wsoap12:body satisfies some $msgname in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name
= $sbody/../../@name]/*[local-name(.) = local-name($sbody/..)]/@message
satisfies every $mpart in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name
= $msgname]/wsdl:part satisfies $mpart/@type or $sbody/@parts and
not(contains($sbody/@parts, $mpart/@name)) |
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: |
{binding}{message with
failed part} |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: er046)
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. TESTABLE BP1211a BP1211b
Test Assertion: |
|
Description: |
Part accessor elements
in the envelope do not have an xsi:nil attribute with a value of
"1" or "true". |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'request' and not (
./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo [not
(@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ) ]
/wsil:messageContents/soap12:Envelope[soap12:Body/* and not
(soap12:Body//soap12:Fault) ] [ some $myenv in . satisfies some $message in
//wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding
[.//wsoap12:*[@style = 'rpc']]/wsdl:operation[@name = fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))]
|
Predicate: |
not (soap12:Body/*/*[attribute::xsi:nil = '1' or attribute::xsi:nil = fn:true()]) |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
Description: |
Part accessor elements
in the response envelope do not have an xsi:nil attribute with a value of
"1" or "true". |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response' or
./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo [not
(@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ]
/wsil:messageContents/soap12:Envelope[soap12:Body/* and not (soap12:Body/soap12:Fault)]
[ some $myenv in . satisfies some $message in //wsdl:definitions/wsdl:message
satisfies ($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:*[@style
= 'rpc']]/ wsdl:operation [fn:string-join((@name, 'Response' ),'' ) =
fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))] |
Predicate: |
not (soap12:Body/*/*[attribute::xsi:nil = '1' or attribute::xsi:nil = fn:true()]) |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w1, w35.2)
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. NOT_TESTED
R2204
(from issue: w1, w35.2)
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. TESTABLE BP2012
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[not(.//wsoap12:*[@style
= 'rpc'])] |
Prerequisite: |
BP2017 |
Predicate: |
every $sbody in wsdl:operation//wsoap12:body satisfies some $msgname in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name = $sbody/../../@name]/*[local-name(.) = local-name($sbody/..)]/@message satisfies every $mpart in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name = $msgname]/wsdl:part satisfies $mpart/@element or $sbody/@parts and not(contains($sbody/@parts, $mpart/@name)) |
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: |
wsoap12:body element(s)
that have non "element" parts attributes. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w1, w35.2)
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). NOT_TESTED
R2212
(from issue: swa094 BP20144) 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.
TESTABLE BP1212a BP1212b
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'request' and not (
./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo [not
(@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ) ]
/wsil:messageContents/soap12:Envelope[soap12:Body/* and not
(soap12:Body//soap12:Fault) ] [ some $myenv in . satisfies some $message in
//wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding
[.//wsoap12:*[@style = 'rpc']]/wsdl:operation[@name = fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))]
|
Predicate: |
some $mbody in
./soap12:Body satisfies some $dbody in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation[@name
= fn:local-name($mbody/*[1])]/wsdl:input/wsoap12:body satisfies some $dopmsg
in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name
= fn:local-name($mbody/*[1])]/*[fn:local-name(.) = 'input'] satisfies some
$dmesg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name
= fn:tokenize(xsd:string($dopmsg/@message), ':' )[fn:last()]] satisfies (
not(wsdl:part) and not($mbody/*/* )) or (every $mpart in $dmesg/wsdl:part
satisfies fn:count($mbody/*/*[fn:local-name(.) = $mpart/@name]) eq 1 or
($dbody/@parts and not(contains($dbody/@parts, $mpart/@name)))) |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response' or ./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[not (@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ]
/wsil:messageContents/soap12:Envelope[soap12:Body/* and not
(soap12:Body/soap12:Fault)] [ some $myenv in . satisfies some $message in
//wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:*[@style
= 'rpc']]/ wsdl:operation [fn:string-join((@name, 'Response' ),'' ) =
fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))] |
Predicate: |
some $mbody in
./soap12:Body satisfies some $dbody in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation[fn:string-join((@name,
'Response'),'') = fn:local-name($mbody/*[1])]/wsdl:output/wsoap12:body
satisfies some $dopmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[fn:string-join((@name,
'Response'),'') = fn:local-name($mbody/*[1])]/*[fn:local-name(.) = 'output' ]
satisfies some $dmesg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name
= fn:tokenize(xsd:string($dopmsg/@message), ':' )[fn:last()] and
wsdl:part/@type] satisfies every $mpart in $dmesg/wsdl:part satisfies
fn:count($mbody/*/*[fn:local-name(.) = $mpart/@name]) eq 1 or ($dbody/@parts
and not(contains($dbody/@parts, $mpart/@name))) |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: swa147)
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. TESTABLE BP1213a BP1213b
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'request' and not ( ./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[not (@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ) ]
/wsil:messageContents/soap12:Envelope[soap12:Body[not (soap12:Fault)]] [ some
$myenv in . satisfies ( every $message in //wsdl:definitions/wsdl:message
satisfies ( (not($message/wsdl:part[1]/@type) ) and ( $myenv/soap12:Body/*[1]
or $myenv/soap12:Header/wsa:Action )) ) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation
[ some $opBinding in . satisfies (if ($target/soap12:Body/*[1] ) then (some
$dmesg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message
[wsdl:part[fn:resolve-QName(xsd:string(@element), . ) = fn:node-name($target/soap12:Body/*[1])]
] satisfies some $dopmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:input
[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) =
$dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ) else fn:true()
) and ( if ($target/soap12:Header/wsa:Action) then ( some $opmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/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' ),'' ) ),'/' ) ) ) and ( $opBinding/@name = $opmsg/../@name ) )
else fn:true() ) ] |
Prerequisite: |
some $myOpBind in
$myOpBinding satisfies ( $myOpBind/../wsoap12:binding[ not (@style = 'rpc' )]
and $myOpBind/wsoap12:operation[ not (@style = 'rpc' )] and $myOpBind/wsdl:input/wsoap12:body[@parts
and (@parts = '' or @parts = ' ' )] ) |
Predicate: |
count(./soap12:Body/*) eq 0 |
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: |
SOAP envelope |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response' or ./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[not (@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ]
/wsil:messageContents/soap12:Envelope[soap12:Body[not (soap12:Fault)]] [ some
$myenv in . satisfies ( every $message in //wsdl:definitions/wsdl:message
satisfies ( (not($message/wsdl:part[1]/@type) ) and ( $myenv/soap12:Body/*[1]
or $myenv/soap12:Header/wsa:Action )) ) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation
[ some $opBinding in . satisfies (if ($target/soap12:Body/*[1] ) then (some
$dmesg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element),
. ) = fn:node-name($target/soap12:Body/*[1])] ] satisfies some $dopmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output
[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) =
$dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ) else fn:true()
) and ( if ($target/soap12:Header/wsa:Action) then ( some $opmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:output
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,
'Response' ),'' ) ),'/' ) ) ) and ( $opBinding/@name = $opmsg/../@name ) )
else fn:true() ) ] |
Prerequisite: |
some $myOpBind in
$myOpBinding satisfies ( $myOpBind/../wsoap12:binding[ not (@style = 'rpc' )]
and $myOpBind/wsoap12:operation[ not (@style = 'rpc' )] and
$myOpBind/wsdl:input/wsoap12:body[@parts and (@parts = '' or @parts = ' ' )]
) |
Predicate: |
count(./soap12:Body/*) eq 0 |
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: |
SOAP envelope |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: swa147)
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. TESTABLE BP1214a BP1214b
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'request' and not ( ./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[not (@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ) ]
/wsil:messageContents/soap12:Envelope[soap12:Body/* and not
(soap12:Body/soap12:Fault) ] [ some $myenv in . satisfies some $message in
//wsdl:definitions/wsdl:message satisfies ($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding
[.//wsoap12:*[@style = 'rpc']]/wsdl:operation [@name = fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))]
|
Prerequisite: |
$myOpBinding/wsdl:input/wsoap12:body[@parts
and (@parts = '' or @parts = ' ' )] |
Predicate: |
count(./soap12:Body/*/*) eq 0 |
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: |
SOAP envelope |
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). 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:
The reported outcomes
have the following meaning:
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: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response' or ./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[not (@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ] /wsil:messageContents/
soap12:Envelope[soap12:Body/* and not (soap12:Body/soap12:Fault)] [ some
$myenv in . satisfies some $message in //wsdl:definitions/wsdl:message
satisfies ($message/wsdl:part[1]/@type) ] |
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:*[@style
= 'rpc']]/ wsdl:operation [fn:string-join((@name, 'Response' ),'' ) =
fn:local-name-from-QName(node-name($target/soap12:Body/*[1]))] |
Prerequisite: |
$myOpBinding/wsdl:output/wsoap12:body[@parts
and (@parts = '' or @parts = ' ' )] |
Predicate: |
count(./soap12:Body/*/*) eq 0 |
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: |
SOAP envelope |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w35.1)
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. TESTABLE BP2113
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//wsoap12:header[@part] or .//wsoap12:headerfault[@part] or .//wsdl:fault/wsoap12:fault[@name] ] |
Predicate: |
(every $shhf in
wsdl:operation//wsoap12:*[local-name(.) = 'header' or local-name(.) =
'headerfault'] satisfies some $msguse in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name
= $shhf/../../@name]/*[local-name(.) = local-name($shhf/..)] satisfies every
$mpart in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name
=
local-name-from-QName(resolve-QName(xsd:string($msguse/@message),$msguse))]/wsdl:part
satisfies $mpart/@element or $shhf/@part and not($shhf/@part = $mpart/@name))
and (every $sf in wsdl:operation/wsdl:fault/wsoap12:fault satisfies some
$msguse in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name
= $sf/../../@name]/wsdl:fault[@name = $sf/@name] satisfies every $mpart in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[@name
=
local-name-from-QName(resolve-QName(xsd:string($msguse/@message),$msguse))]/wsdl:part
satisfies $mpart/@element) |
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: |
Defective wsdl:binding
and wsdl:part elements. |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: bp12015)
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
. TESTABLE BP2114
Test Assertion: |
|
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: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding |
Predicate: |
some $bing in
self::node() satisfies |
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: |
{Defective
wsdl:binding element}{message with part(s) unbound} |
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). 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:
The reported outcomes
have the following meaning:
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
(from issue: w3cw42)
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. TESTABLE BP2115
Test Assertion: |
|
Description: |
An "element"
attribute on any wsdl:part element refers to a global element declaration. |
Target: |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part/@element] |
Predicate: |
every $part in
wsdl:part[@element] satisfies some $ged in //xsd:schema/xsd:element satisfies
( ( $ged/../@targetNamespace = namespace-uri-from-QName(
resolve-QName(xsd:string($part/@element),$part)) or (not
($ged/../@targetNamespace) and not (namespace-uri-from-QName(
resolve-QName(xsd:string($part/@element),$part)) ) ) ) and local-name-from-QName(resolve-QName(xsd:string($part/@element),$part))
= $ged/@name ) |
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: |
Defective wsdl:message element. |
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). 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:
The reported outcomes have the following meaning:
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:
|
INCORRECT:
<message name="GetTradePriceInput">
<part
name="tickerSymbol" element="xsd:string"/>
</message>
CORRECT:
<message name="GetTradePriceInput">
<part
name="body" element="tns:SubscribeToQuotes"/>
</message>
This section of
the Profile incorporates the following specifications by reference:
In WSDL 1.1, wsdl:portType
elements 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 (from issue: w5)
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. TESTABLE BP1111a
BP1111b
BP1012a
BP1012b
Test Assertion: |
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message [@type = 'request'
and not ( ./wsil:messageContents/soap12:Envelope/soap12:Header/wsa:RelatesTo
[not (@RelationshipType) or ( @RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' ) ] ) ]
/wsil:messageContents/soap12:Envelope[soap12:Body[not (soap12:Fault)]] [ some
$myenv in . satisfies ( every $message in //wsdl:definitions/wsdl:message
satisfies ( (not($message/wsdl:part[1]/@type) ) and ( $myenv/soap12:Body/*[1]
or $myenv/soap12:Header/wsa:Action )) ) ] |
co-Target: myOpBinding |
<cotarget
xmlns="http://www.ws-i.org/2002/08/12/ProfileDoc-2.0.xsd"
xmlns:h="http://www.ws-i.org/2002/08/12/ProfileMarkup-2.0.xsd" xmln |