Assert Yourself!

[Introduction] | [How To] | [Review Assignments]

Introduction

This document describes how to add testable assertions to the WSDL 2.0 specifications and assigns sections to members of the Working Group. The task of identifying all the testable assertions is very important since it will help us create a comprehensive test suite. It will also help implementers produce high quality implementations.

What is a Testable Assertion?

A testable assertion is a normative requirement in our specifications that can be checked by a validation program. Testable assertions should include one of the RFC 2119 keyowrds. Initially, we should focus on the keywords MUST, MUST NOT, SHALL, SHALL NOT, and REQUIRED since these are map to error conditions. We should also address the keywords SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL since these map to warnings and we want users of the specification to follow Best Practices.

How Do I Markup a Testable Assertion?

We have defined a special XML tag: <assert> that is placed around the testable assertion. Here's an example:

       	<assert class="document" id="Import-0001">
       		However, any WSDL 2.0 document that contains component
       		definitions that refer by QName to WSDL 2.0 components
       		that belong to a different namespace MUST contain a
       		<el>wsdl:import</el>
       		&EII;
       		for that namespace (see
       		<specref ref="imports" />
       		).</assert>

• id - a required identifier. The identifier consists of a descriptive prefix and a unique numeric suffix separated by a dash, as in Import-0001 . The numeric suffix must be globally unique across all our specifications. Once this number is assigned, it never changes. It may be removed but will never be reused. The identifier as a whole must be stable since implementers will refer to it.
• class - a required classification of the assertion. The valid classes are: component, document, exchange, and message.
  • A component assertion is a requirement on WSDL 2.0 components, e.g. that an Interface must not extend itself.
  • A document assertion is a requirement on WSDL 2.0 documents, e.g. that a document must not import its own namespace.
  • An exchange assertion is a requirement on Web service message exchanges, e.g. that a fault may replace a message.
  • A message assertion is a requirement on concrete Web service messages, e.g. that a SOAP message body satsifies a certain XML schema.
• required - an optional boolean that indicates if the assertion is mandatory or suggested. The default is true.
  • Use false for SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, or OPTIONAL requirements.
  • Use true for MUST, MUST NOT, SHALL, SHALL NOT, or REQUIRED requirements.

Review Assignments