Copyright © 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
NOTE: This document has been obsoleted by a more recent version.
This document draws a list of testable assertions found in the SOAP Version 1.2 specification, and provides a set of tests in order to show whether the assertion is implemented in a SOAP processor.
The goal of this document is to get a list of features whose implementation can be tested in order to satisfy the entrance criteria of the Proposed Recommendation stage.
It is incorrect to claim to be compliant with the SOAP Version 1.2 specification by passing successfully all the tests provided in this test suite. An implementation which would pass all the tests below may claim to be compliant with the test suite dated $Date: 2001/11/16 21:06:05 $.
This document is an editors' copy that has no official standing.
This document has been produced by the W3C XML Protocol Working Group. All information in this document is to be considered as work in progress.
Contributions to this document are encouraged. Please refer to W3C SOAP Version 1.2 test collection - How to contribute to find out more about contributing.
This version is based on the 2001/11/08 14:16:59 editors' copies of the SOAP Version 1.2 part 1 and part 2 specifications.
Please refer to the latest SOAP Version 1.2 Working Drafts (part 1 and part 2) for any normative information.
Please send comments on this document to xml-dist-app@w3.org (public archive), especially if something is missing from this list of assertions.
Core specification tests
Encoding tests
RPC convention tests
HTTP binding tests
Changelog
This section reproduces the structure of the SOAP Version 1.2 Working Draft. The tests have been grouped into four categories: the core features from the messaging framework specification, tests regarding the RPC convention, the SOAP encoding and the HTTP binding as defined in the adjuncts specification.
Assertions are given a unique number. Should assertions be modified, the assertion number will be changed so that tests can be easily named.
A means assertion. Test are numbered as AxTy, when x is the assertion number.
SOAPBuilders interoperability tests have been classified in this document. They are numbered as follows: SBRng, meaning SOAPBuilders round n, group g. Some tests are listed as testing two assertions (e.g. arrays and structs). Obviously, structs and arrays can use simple types, but this is not listed as such to avoid making the document too complex.
All the tests follow the following rules:
Communication with the SOAP processor tested is done by HTTP, using the HTTP binding described in the adjuncts specification.
The node tested must act as the actor http://www.w3.org/2000/xp/Group/1/09/ts-tests/test.
Part 1 Section 2.1: SOAP Nodes
A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model and, if appropriate, generate SOAP faults, SOAP responses and send additional SOAP messages, as provided by the remainder of this specification.
The implementation of this assertion is tested by the entire test suite.
No test designed for this assertion yet!
None proposed.
Part 1 Section 2.2: SOAP Actors and SOAP Nodes
Each SOAP node MUST act in the role of the special SOAP actor named "http://www.w3.org/2001/09/soap-envelope/actor/next", and can additionally assume the roles of zero or more other SOAP actors.
Other header blocks with unrecognized values for the actor attribute must be ignored.
SB tests do not cover the case of the URI of the node, they only cover the .../next URI case.
SBR2C tests: SBR2 echoMeStringRequest which uses mustUnderstand="0"; SBR2 echoMeStructRequest which uses mustUnderstand="1"; SBR2 unknown header entry which uses a combination of both.
The following tests use the SOAP module identified by the URI http://www.w3.org/2000/xp/Group/1/09/ts-tests/echoOK. When processing an echoOK module, the SOAP processor must return an responseOK in the same namespace, with a value of OK.
The node tested is sent a message containing a block echoOk block targetted to http://www.w3.org/2001/06/soap-envelope/actor/next:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:echoOK
xmlns:m="http://www.w3.org/2000/xp/Group/1/09/ts-tests/echoOK"
env:actor="http://www.w3.org/2001/06/soap-envelope/actor/next"/>
</env:Body>
</env:Envelope>
The tested node returns a SOAP message containing a responseOK block in the body, whose value is OK:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:responseOK
xmlns:m="http://www.w3.org/2000/xp/Group/1/09/ts-tests/echoOK">OK</m:responseOK>
</env:Body>
</env:Envelope>
The node tested is sent a message containing a block echoOk block targetted to http://www.w3.org/2000/xp/Group/1/09/ts-tests/tested:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:echoOK
xmlns:m="http://www.w3.org/2000/xp/Group/1/09/ts-tests/echoOK"
env:actor="http://www.w3.org/2000/xp/Group/1/09/ts-tests/tested"/>
</env:Body>
</env:Envelope>
The tested node returns a SOAP message containing a responseOK block in the body, whose value is OK:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:responseOK
xmlns:m="http://www.w3.org/2000/xp/Group/1/09/ts-tests/echoOK">OK</m:responseOK>
</env:Body>
</env:Envelope>
Part 1 Section 2.2: SOAP Actors and SOAP Nodes
A SOAP node can establish itself as the ultimate SOAP receiver by acting in the (additional) role of the anonymous SOAP actor.
Another similar assertion later?
Pretty much any RPC test is redundant with this.
SBR1 tests; SBR2A tests; SBR2B tests
The node tested is sent a message containing a block echoOk block targetted to the anonymous actor:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:echoOK
xmlns:m="http://www.w3.org/2000/xp/Group/1/09/ts-tests/echoOK"/>
</env:Body>
</env:Envelope>
The tested node returns a SOAP message containing a responseOK block in the body, whose value is OK:
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env:Body>
<m:responseOK
xmlns:m="http://www.w3.org/2000/xp/Group/1/09/ts-tests/echoOK">OK</m:responseOK>
</env:Body>
</env:Envelope>
Part 1 Section 2.2: SOAP Actors and SOAP Nodes Headers
SOAP nodes MUST NOT act in the role of the special SOAP actor named "http://www.w3.org/2001/09/soap-envelope/actor/none".
No test designed for this assertion yet!
Part 1 Section 2.4: Understanding SOAP Headers
SOAP header blocks carry optional attribute information items with a local name of
mustUnderstandand a namespace name of http://www.w3.org/2001/09/soap-envelope (see 4.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true", the SOAP block is said to be mandatory. For such SOAP blocks the targeted SOAP node MUST: either process the SOAP block according to the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block; or not process the SOAP message at all, and generate a fault (see 4.4 SOAP Fault).
Check how A4, A5 and A6 are related (in the spec, and for the tests).
No test designed for this assertion yet!
Send an understandable mustUnderstand block.
Send an ununderstandable (??) mustUnderstand block.
SB tests: check A5 and A6.
Part 1 Section 2.5: Processing SOAP Messages
Generate a single SOAP MustUnderstand fault (see 4.4.2 MustUnderstand Faults) if one or more SOAP blocks targeted at the SOAP node are mandatory and are not understood by that node. If such a fault is generated, any further processing MUST NOT be done.
Some commonality with A4.
No test designed for this assertion yet!
Send one not understandable mustUnderstand block.
Send several not understandable mustUnderstand block.
Check processing and the fault returned.
Send a combination of blocks and check that the SOAP node does the right thing (needs details; see the example from the Dinard face-to-face).
SBR2C tests: SBR2 unknown header entry element unknown header sent with mustUnderstand="0"/"1" targetted to the/another SOAP node
Part 1 Section 2.5: Processing SOAP Messages
A SOAP node MUST process SOAP blocks targetted at it that are identified as mandatory.
Some commonality with A4.
SB tests should cover this.
No test designed for this assertion yet!
Send one mustUnderstand block.
Send several mustUnderstand blocks.
Check that they are processed.
SBR2C tests: SBR2 echoMeStructRequest sends an understandable header with mustUnderstand="1".
Part 1 Section 2.5: Processing SOAP Messages
If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body blocks from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored). Additional SOAP header blocks MAY be inserted at any point in the SOAP message, and such inserted SOAP header blocks MAY be indistinguishable from one or more just removed (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)
Check that a SOAP node behaves correctly as an intermediary.
No test designed for this assertion yet!
Check that the targeted blocks (both with .../next and a particular URI) are removed.
Check that all the others are present in the original order (use IDs to distinguish them).
Not quite sure what is to be done for blockc that turn out to be re-inserted into the message - cannot prove it
Part 1 Section 3: Relation to XML
A SOAP node MUST ensure that all element information items and attribute information items in messages that it generates are correctly namespace qualified. A SOAP node MUST be able to process SOAP namespace information in messages that it receives. It MUST treat messages with incorrect namespace information as a version error (see 4.1.2 Envelope Versioning Model).
No test designed for this assertion yet!
Send a message with an unknown namespace.
Send a message without any namespace.
Part 1 Section 3: Relation to XML
Schema documents for these namespaces can be found by dereferencing the namespace identifiers. These schemas are normative.
the schema for the SOAP namespaces is the 'gold standard' against which all envelopes will be applied. It should be correct!
No test designed for this assertion yet!
attempt to access the schema document
apply schema document to an envelope instance
Part 1 Section 3: Relation to XML
A SOAP message MUST NOT contain a Document Type Declaration. On receipt of a SOAP message containing a Document Type Declaration, a SOAP receiver MUST generate a fault (see 4.4 SOAP Fault) with faultcode of "Client.DTD".
No test designed for this assertion yet!
send a SOAP message with a DTD and check for failure
Part 1 Section 3: Relation to XML
A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages it receives.
No test designed for this assertion yet!
send a SOAP message with a PI and check that it is ignored
Part 1 Section 3: Relation to XML
A SOAP message MUST NOT impose any XML schema processing (assessment and validation) requirement on the part of any receiving SOAP node.
Probably not testable.
No test designed for this assertion yet!
Part 1 Section 4: SOAP Envelope
The introduction of section 4 explains the structure of a SOAP message.
The structure of the envelope could be checked on every test, and this would not require an extra test.
No test designed for this assertion yet!
@@@
Part 1 Section 4.1.1: SOAP encodingStyle Attribute
The encodingStyle attribute information item is a whitespace delimited list where each item in the list is of type anyURI in the namespace http://www.w3.org/2001/XMLSchema.
No test designed for this assertion yet!
if an encoding style is present, check the namespace, the schema type and the structure of the list (ie whitespace delimited, using all different types of whitespace)
Part 1 Section 4.1.1: SOAP encodingStyle Attribute
all URIs syntactically beginning with "http://www.w3.org/2001/09/soap-encoding" indicate conformance with the SOAP encoding rules defined in [1](SOAP Encoding), though with potentially tighter rules added.
No test designed for this assertion yet!
check that everything using this URI root will conform to encoding tests
Part 1 Section 4.1.1: SOAP encodingStyle Attribute
A value of the zero-length URI ("") explicitly indicates that no claims are made for the encoding style of contained elements. This can be used to turn off any claims from containing elements.
does this means that the 'claims' can be turned off forever or for just the scope of the element on which the encodingStyle attribute is attached
No test designed for this assertion yet!
check that the "" URI is accepted
check that the "" URI switches off a previous encoding style
check the scope of this 'switch off'
Part 1 Section 4.1.2: Envelope Versioning Model
If a SOAP message is received by a SOAP 1.2 node in which the document element information item does NOT have a local name of Envelope and a namespace name of http://www.w3.org/2001/09/soap-envelope the SOAP node MUST treat this as a version error and generate a VersionMismatch SOAP fault (see 4.4 SOAP Fault). A SOAP VersionMismatch fault message MUST use the SOAP/1.1 envelope namespace "http://schemas.xmlsoap.org/soap/envelope/" (see A Version Transition From SOAP/1.1 to SOAP Version 1.2).
No test designed for this assertion yet!
Send a message with a different namespace and check tha that a fault returns and that the fault is the correct one.
Check that the fault is using the 1.1 envelope namespace
Part 1 Section 4.2: SOAP Header
The
Headerelement information item has:
A local name of
HeaderA namespace name of http://www.w3.org/2001/09/soap-envelope
Zero or more namespace qualified attribute information item children.
Zero or more namespace qualified element information item children.
All child element information items of the SOAP Header are called SOAP header blocks.
Each SOAP header block element information item:
MUST be namespace qualified;
MAY have an
encodingStyleattribute information itemMAY have an
actorattribute information itemMAY have a
mustUnderstandattribute information item
As for DA9, the syntax should be checked at every test.
No test designed for this assertion yet!
tests are pretty much specified in the quote above!
Part 1 Section 4.2.1: Use of Header Attributes
A SOAP receiver MUST ignore all SOAP header block attribute information items that are applied to other descendant element information items of the SOAP
Headerelement information item.
No test designed for this assertion yet!
Send a message with the actor and mustUnderstand attributes randomly located on elements.
Part 1 Section 4.2.1: Use of Header Attributes
SOAP header block attribute information items MUST appear in the SOAP message itself in order to be effective; default values which may be specified in an XML Schema or other description language do not affect SOAP processing (see 3 Relation to XML).
No test designed for this assertion yet!
provide a schema that defaults a value and check that it fails
Part 1 Section 4.2.3:SOAP mustUnderstand Attribute
The type of the
mustUnderstandattribute information item is boolean in the namespace http://www.w3.org/2001/XMLSchema. Omitting this attribute information item is defined as being semantically equivalent to including it with a value of "false".
No test designed for this assertion yet!
Test with a "false" value and without a value and check that the results are the same
Part 1 Section 4.4: SOAP Fault
If present, the SOAP
FaultMUST appear as a SOAP body block and MUST NOT appear more than once within a SOAP Body.
This should be tested in every scenario in which a fault is expected.
No test designed for this assertion yet!
@@@
Part 1 Section 4.4: SOAP Fault
Section 4.4 describes the structure of a fault element, plus:
[The detail element information item] MUST be present when the contents of the SOAP Body could not be processed successfully. It MUST NOT be used to carry error information about any SOAP header blocks. Detailed error information for SOAP header blocks MUST be carried within the SOAP header blocks themselves.
This should be tested in every scenario in which a fault is expected.
No test designed for this assertion yet!
Additional test: check that details about a fault in a header isn't carried in the detail element but in header blocks.
Part 1 Section 4.4.1: SOAP Fault Codes
The SOAP
faultcodevalues defined in this section MUST be used as values for the SOAPfaultcodeelement information item when describing faults defined by SOAP 1.2 Part 1 (this document). The namespace identifier for these SOAPfaultcodevalues is "http://www.w3.org/2001/09/soap-envelope".
No test designed for this assertion yet!
Trigger a number of faults and check that the appropriate faultcode is used.
Part 1 Section 4.4.2: MustUnderstand Faults
Section 4.4.2 defines the syntax of a mustUnderstand fault, i.e. the syntax of the Misunderstood element.
The syntax could be tested. However, this error reporting mechanism is not mandatory. The syntax should be tested when faults are generated, if this is the case that the Misunderstood element is used.
No test designed for this assertion yet!
@@@
Part 2 Section 4: SOAP Encoding
The data serialized according to the rules defined in this section MAY contain references to data outside the serialization. When present, these references MUST be Uniform Resource Identifiers.
No test designed for this assertion yet!
Part 2 Section 4.1: Rules for Encoding Types in XML
SOAP uses unqualified attribute information items with a local name of id and a type of ID in the http://www.w3.org/2001/XMLSchema namespace to specify the unique identifier of an encoded element.
Not sure about what to do with this assertion.
No test designed for this assertion yet!
send a SOAP message with a id attributes and validate with schema
perhaps check that the encoded element is indeed unique
Part 2 Section 4.1: Rules for Encoding Types in XML
SOAP uses unqualified attribute information items with a local name of href and a type of anyURI in the http://www.w3.org/2001/XMLSchema namespace to specify a reference to such a value, in a manner conforming to the XML Specification[8], XML Schema Specification[5], and XML Linking Language Specification[9].
No test designed for this assertion yet!
send a SOAP message with a href attribute and validate with schema
pull out relevant information in the referenced specifications to ensure that the there is conformance
Part 2 Section 4.1: Rules for Encoding Types in XML
All values are represented as element content. A multi-reference value MUST be represented as the content of an independent element.
No test designed for this assertion yet!
@@@
Part 1 Section 4.1: Rules for Encoding Types in XML
For each element containing a value, the type of the value MUST be represented by at least one of the following conditions: (a) the containing element instance contains an
xsi:typeattribute, (b) the containing element instance is itself contained within an element containing a (possibly defaulted)enc:arrayTypeattribute or (c) or the name of the element bears a definite relation to the type, that type then determinable from a schema.
Should be tested every time a response is received from the SOAP node tested.
No test designed for this assertion yet!
Part 2 Section 4.2: Simple Types
Section 4.1 and section 4.2 define simple values.
All simple values MUST be encoded as the content of elements whose type is either defined in "XML Schema Part 2: Datatypes" Specification [11], or is based on a type found there by using the mechanisms provided in the XML Schema specification.
Implementations should be tested to ensure that they understand simple values.
A variety of types should be used, including the examples found in the SOAP Version 1.2 specification (subsections of section 5.2).
SB tests are pretty extensive.
No test designed for this assertion yet!
SBR1 tests: SBR1 echoString; SBR1 echoInteger; SBR1 echoFloat; SBR1 echoBase64; SBR1 echoDate
SBR2A tests: SBR2 echoString; SBR2 echoInteger; SBR2 echoFloat; SBR2 echoBase64; SBR2 echoDate; SBR2 echoDecimal; SBR2 echoBoolean
SBR2B tests: SBR2 echoStructAsSimpleTypes; SBR2 echoSimpleTypesAsStruct
Part 2 Section 4.3: Polymorphic Accessor
A polymorphic accessor instance MUST contain an
xsi:typeattribute that describes the type of the actual value.
Not sure what/how to test that.
No test designed for this assertion yet!
Part 2 Section 4.4: Compound Types
Part 2 Section 4.4.1: Compound Values and References to Values
Section 4.1 and section 4.4 & 4.4.1 define compound values.
A "struct" is a compound value in which accessor name is the only distinction among member values, and no accessor has the same name as any other.
Implementations should be tested to ensure that they understand compound values.
SB tests pretty extensive.
No test designed for this assertion yet!
SBR1 tests:SBR1 echoStruct; SBR1 echoStructArray
SBR2A tests: SBR2 echoStruct; SBR2 echoStructArray
SBR2B tests: SBR2 echoStructAsSimpleTypes; SBR2 echoSimpleTypesAsStruct; SBR2 echoNestedStruct; SBR2 echoNestedArray
Part 2 Section 4.4: Compound Types
Part 2 Section 4.4.1: Compound Values, Structs and References to Values
Sections 4.1 and 4.4.1 define multi-reference values.
Implementations should be tested to ensure that they understand multi-reference values.
No test designed for this assertion yet!
Part 2 Section 4.4: Compound Types
Part 2 Section 4.4.2: Arrays
Sections 4.1 and 4.4.2 define arrays.
Implementations should be tested to ensure that they understand arrays.
SB tests pretty extensive.
No test designed for this assertion yet!
SBR1 tests: SBR1 echoStringArray; SBR1 echoIntegerArray; SBR1 echoFloatArray; SBR1 echoStructArray
SBR2A tests: SBR2 echoStringArray; SBR2 echoIntegerArray; SBR2 echoFloatArray; SBR2 echoStructArray
SBR2B tests: SBR2 echo2DStringArray; SBR2 echoNestedArray
Part 2 Section 4.4.2.1: Partially Transmitted Arrays
A partially transmitted array indicates in an
enc:offsetattribute the zero-origin offset of the first element transmitted.
Test the understanding of the enc:offset attribute.
No test designed for this assertion yet!
Part 2 Section 4.4.2.2: Sparse Arrays
Each element representing a member value contains a
enc:positionattribute that indicates its position within the array.
Test the understanding of the enc:position attribute.
No test designed for this assertion yet!
Part 2 Section 5.1: RPC and SOAP Body
The name of the return value accessor is "result" and it is namespace-qualified with the namespace identifier "http://www.w3.org/2001/09/soap-rpc" The return value accessor MUST be present if the return value of the procedure is non-void. The return value accessor MUST NOT be present if the return value of the procedure is void.
No test designed for this assertion yet!
Part 2 Section 5.1: RPC and SOAP Body
Section 5.1 states the rules for RPCs.
Most of the tests will use RPCs, so the syntax of the response should be tested.
SB tests make use of this.
No test designed for this assertion yet!
SBR1 tests; a particular case is tested by SBR1 echoVoid (no arguments in nor out).
SBR2 tests; a particular case is tested by SBR2 echoVoid (no arguments in nor out).
Part 2 Section 5.2: RPC and SOAP Header
Additional information relevant to the encoding of an RPC invocation but not part of the formal procedure or method signature MAY be expressed in the RPC encoding. If so, it MUST be expressed as a header block.
No test designed for this assertion yet!
Send an RPC with some extra information in a header
block.
Part 2 Section 5.3: RPC Faults
Errors arising during RPC invocations are reported according to the following rules (in decreasing order of precedence):
A
soap-env:Serverfault SHOULD be generated when the server cannot handle the message because of some temporary condition, e.g. when it is out of memory.A
soap-env:DataEncodingUnknownfault SHOULD be generated when the arguments are encoded in a data encoding unknown to the server.An
rpc:ProcedureNotPresentfault MUST be generated when the server cannot find the procedure specified.An
rpc:BadArgumentsfault MUST be generated when the server cannot parse the arguments or when there is a mismatch between what the server expects and what the client has sent.Other faults arising in an extension or from the application SHOULD be generated as described in [1](SOAP Faults).
No test designed for this assertion yet!
Part 2 Section 6: Using SOAP in HTTP
HTTP applications MUST use the media type "application/soap" according to RFC 2376 when including SOAP messages in HTTP exchanges.
No test designed for this assertion yet!
Test that application/soap SOAP data is processed for an HTTP request.
Check that HTTP response containing a SOAP message is using the correct media type.
Part 2 Section 6.1: SOAP HTTP Request
this binding only defines SOAP within HTTP POST requests
If HTTP is the binding used for the tests, this will be verified at each tests. Maybe check that SOAP message is correctly embedded (Host header, Content-Length, etc). HTTP/1.1 validity?
No test designed for this assertion yet!
Part 2 Section 6.1.1: The SOAPAction HTTP Header Field
If a SOAP Receiver does require SOAPAction's presence in order to operate, it MUST respond to requests which either contain an unrecognised SOAPAction header value or do not contain a SOAPAction header with a 427 "SOAPAction Required" HTTP response status code. Such response messages MAY contain a 'Required-SOAPAction' HTTP response header field, whose value is the URI which can be used in the SOAPAction request header field to re-submit the request.
No test designed for this assertion yet!
Part 2 Section 6.1.1: The SOAPAction HTTP Header Field
Support for SOAPAction is OPTIONAL in implementations. Implementations SHOULD NOT generate or require SOAPAction UNLESS they have a particular purpose for doing so (e.g., a SOAP Receivers specifies its use).
Check that SOAPAction isn't always required? "particular purpose" is vague
No test designed for this assertion yet!
Part 2 Section 6.2: SOAP HTTP Response
SOAP over HTTP follows the semantics of the HTTP Status codes for communicating status information in HTTP. For example, a 2xx status code indicates that the client's request including the SOAP component was successfully received, understood, and accepted etc.
If an error occurs while processing the request, the SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP message in the response containing a SOAP fault (see SOAP Faults) indicating the SOAP processing error.
Get a series of tests testing different cases. Will probably be covered by other tests.
No test designed for this assertion yet!
Integrated changes made in the spec. Now in sync 2001/11/08 14:16:59 editors' copies.
New version from Oisin. Incorporated new assertions from the 2 October drafts.
Finished conversion to XML.
Grouped tests in categories.
Rewrote the boilerplate and intro to reflect face-to-face
decision to develop this document.
Wrote some tests.
Removed DA/A distinction.
Evaluation of the SB tests.
Added a references section
for the As.
First version of the draft. Very rough.