[ebxml-iic] Latest Abstract Test Suite Format for review/ Monday'sconf call

[Michael Kass <michael.kass@nist.gov>]

To Jacques and all,

   I have followed up on Jacques recommendation of using a modified XPath 
syntax to describe both XML message manipulation and query as well as MIME 
header construction and query.

   I've attached a ZIP file of the test suite XML file, along with an XSLT 
stylesheet and schema for test document.  Please unzip into a directory on 
a windows machine, and bring up the file 
"ebxml_ms_20_abstract_testsuite.xml" in your IE browser.  If you have the 
proper MSXML parser installed, you should see a nice HTML table displaying 
the new format.  Below is a description of the Abstract Test Table:

******************************************************************************************************************************************************************************************

The purpose of this is to provide a unified syntax for test case 
representation in an  abstract sense only.  The goal is also to further 
simplify the current Abstract Test Suite table, so that any test developer 
could understand what is required to unambiguously constrct a test case.  I 
believe that this syntax has done that.

How these test would actually be described and implemented for actual 
testing would be left up to the test driver implementer.

I believe that I have accurately described both message construction as 
well as query with these first 70+ test descriptions.  I use the modified 
XPath syntax to describe MIME header containers as elements, and header 
values as attributes.  Since SOAP and ebXML messages are nested inside of 
MIME containers, we could describe both message query and manipulation of 
content relative to the MIME container that we are searching for or 
constructing.

We know that the SOAP MIME container is first container in the MIME 
message, and all other references to payloads can be done via Content-ID or 
Content-Location. We have a "context" for referencing sub-elements and 
attributes of our MIME container, as well as referencing the "parent" 
element ( in this case the main MIME header of the message ).  We could 
even search messages across TestCases in our "virtual persistent store" if 
we include an additional higher "parent" element called <TestCaseMessage 
id="myTestCaseId">

In any event, PutMessage and GetMessage operations/methods always 
create/search for a <MIME:Container> element ( or elements ) 
respectively.  They would, in an abstract sense, generate or return a 
"NodeList" that other methods could act upon.   All subsequent "child" 
operations, such as <ebTest:ConformanceCondition> or <ebTest:PreCondition> 
elements describe their search path  "relative" to that <MIME:Container> 
element.

The differences between our modified XPath syntax for query vs. 
modification is quite subtle.  The assignment operator for modification is 
"=".   The comparison operator for query is "==".  The test writer is 
further aided in differentiating the syntax by the use of the <GetMessage> 
and <PutMessage> operation names ( signifying query vs. 
construction/modification).

A NodeList ( in most cases a single node, or returned <MIME:Container> 
element ) is selected by using the modified XPath syntax.  Searching ( in a 
<GetMessage> operation )  uses a relative path description to select MIME 
messages from the abstract  "persistent store" of returned MIME messages 
for a particular test case.

If  we are doing message construction ( a <PutMessage> operation ), the 
NodeList is a single element that uses the same syntax to create a 
<MIME:Container> element for either the SOAP/ebXML message or a MIME 
message payload.  The "and" operator aggregates the assignment operations 
for that particular <MIME;Container> and its sub-elements.

The only difference in syntax between message construction <PutMessage> and 
message query <GetMessage> syntax is the use of the equivalence operators 
"=" and "==" respectively.  All other semantics (e.g use of the "and" to 
indicate aggregation ) remain the same.

Syntax to express the <Precondition> and <ConformanceCondition> operations 
follow the same modified XPath rules, with the additional requirement that 
their "path" must be "relative" to the <MIME:Container> element described 
in the <PutMessage> or <GetMessage> parent element.

Parameters ( passed into an XML processor ) are represented with the 
"$"symbol preceeding them.  These represent dynamically created values that 
are passed into the message construction or message query processor to be 
used in comparison or assignment operations.  Values like "MessageId", 
"ConversationId" and others would most likely be "autogenerated" by a Test 
Driver, and as such, are not specified for these test cases.

I agree with Jacques, that from an "abstract" sense, this is a more 
understandable syntax to use to describe tests.    Actually, if one 
implemented a test driver that reformatted MIME headers and their values 
"from" and "to" XML, and a "persistent store" of ebXML messages is 
represented, say in an XML database, then this abstract test suite could in 
fact be used to construct and drive actual tests.

At the very least though, it can be viewed as a non-ambiguous description 
of conformance tests for ebXML MS v2.0, that could be implemented by anyone 
however they see fit.

( If the interoperability folks would like, I would be happy to attempt to 
describe their interop tests in this format. ).

All of this is now coded in XML.  The attached HTML document is a 
transformation to aid in viewability/understandability.

If this format is acceptable to the IIC, then I can begin describing the 
remaining test cases against our test requirements.  You see that many test 
cases are not described in the current document.

I have not described all tests in the table due to questions about their 
validity or limitation in adequately describing the tests.  This is an 
issue that we will need to address once the list is completed, but these 
remaining test cases have not been resolved.

Also of note:  I needed less than 5 CPA descriptors in constructing these 
tests ( very few modifications, I believe, would be necessary to a 
"base_cpa" to execute these first 100 tests.

Comments?

Mike

Attachment: ebXML_Abstract_Test_Suite.zip
Description: Zip archive