[ebxml-iic] Updated schemas for test suite

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

Matt and all,

I’m sending a list of proposed modifications that I made to the
ebXMLTestSuite.xsd schema, prior to writing documentation on it.  If
you agree with this, I’ll check the schema into CVS for documentation. In
addition, I am attaching the modified schema(s) as a ZIP file, along with
a JPG image reflecting the new design ( to help see changes ). 
Below, I have listed the modifications, and some comments.

Schema Issues  ebXMLTestSuite.xsd ( going hierarchically down the
tree )

1)      <TestSuite/> - No change

2)      <Documentation/> .. just a question ../. what “types” of documentation would we provide for the @type?

3)      <Message/> - modified to be either Xupdate or “API-driven”  I propose to the IIC that ebXML Message Header and Body be manipulated using simple XML message syntax, similar to existing message syntax.  The idea being that a parser of of the “API-driver” XML would make calls to modify a default ebXML Message document object, using a simple syntax virtually identical to the existing ebXML Messaging XML.  This will free implementors from having to use template technology to construct ebXML messages, and could broaden the implementation of the testing framework, since there are many implementations of Messaging out there already that could tie into this framework.  It would also be more efficient from a Test Driver implementation standpoint.   Payload content, however would still use template technology for modifications, since there is no application-level API to use.

4)      <Query/> - A new element to represent stored, commonly used XPath queries ( like message correlation query ).  This is defined assuming an XPath implementation.

5)      <Template/>  - No proposed changes here.

6)      <TestCase/> added an “id” attribute, for referencing from the master profile list at runtime.

7)      <TestStep> have added a “party” attribute to reflect which ( “TestDriver/TestService” runs the step), and removed @passMessage, @failMessage, @stepDriver, @stepName and stepId as unnecessary info ( since PutMessage and GetMessage child elements provide that info ).

8)      <ConfigurationItem/> and <ConfigurationGroup/> …  I am not sure exactly how these will work, and will wait to see Matt’s documentation on this…  I know that we need test driver configuration, defined at the <TestCase> and <TestStep> level.

9)      <PutMessage/>  Put “main” MIME header attributes ( like “start” and “content-type” ) here.  These are not to be confused with the MIME container for the SOAP envelope.  I also created a “pair” of elements to represent any <MIME/> header, and its corresponding <MIMEHeaderValue/>.  This gives test writer ability to manipulate values as appropriate.

10)     <MessageRef/> and <Message/> are new.  I think that “commonly used” messages should reside in memory, and be callable via reference.  Other messages, not commonly used, could be “inlined inside  a <Message/> envelope.

11)     <SetPayload/> is now nested inside <SetMessage/> to reflect parent/child relationship.  Again <MIMEHeader/> and <MIMEHeaderValue/>  can be manipulated for a payload as well.

12)     <GetMessage/> retrieves message from persistent store for a particular <TestCase/>.  Messages can be correlated based upon a <QueryRef/> ( to an existing, commonly used XPath query ) or an “inlined” <Query/>. 

13)     We introduced the <TestPreCondition/> and <TestConformanceCondition/> operations in discussion in the IIC mailing list, as a way to distinguish types of tests performed upon returned messages. These have been added as child elements to the <GetMessage/> element.

14)     <GetPayload/> is now a child element of <GetMessage/>, since payloads will be evaluated based upon a particular returned message. Payloads can be filtered first based upon <MIMEHeader/> content ( such as CID ), then can be further evaluated using queries in <TestPreCondition> and <TestConformanceCondition>.

*** These are the proposed changes that I would like to make to this
schema, and  reflect discussion in the IIC over the past few
months.  In addition, I would like to find out what IIC members
think about using a more “API-like” approach to ebXML message
construction, as opposed to “template manipulation”.   I
propose this approach because we could perhaps get additional
implementations of test drivers if we provide a framework that is easier
to port to existing messaging implementations.
On the other hand, I think that template manipulation is a logical choice
for PAYLOAD construction, since payload content reflects application
data, where no common underlying API exists.

Comments?


Mike

Attachment: ebXMLTestSuite.jpg
Description: JPEG image

Attachment: ebXMLTestSuite.zip
Description: Zip archive