OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ebxml-iic] Updated schemas for test suite

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.



Attachment: ebXMLTestSuite.jpg
Description: JPEG image

Attachment: ebXMLTestSuite.zip
Description: Zip archive

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC