Re: [ebxml-iic] Errata list for versoin 2.0 of IIC Test Framework

----- Original Message -----

To: Michael Kass ; Jacques Durand ; ebxml-iic@lists.oasis-open.org

Sent: Thursday, September 25, 2003 3:20 PM

Subject: RE: [ebxml-iic] Errata list for versoin 2.0 of IIC Test Framework

Here are comments from my team on the erratta list:

1. Would like to specify a schematron file to use for validation. It could be as simple as adding an additional type for the existing attribute contentType on <ValidateContent>

For instance:

contentType="SchematronFile" or "Schematron"

[MIKE] - This looks doable. I will add this to the proposed new schema and Errata.

2. Please clarify or elaborate the difference between <SetParameter> in GetMessage and the nested SetParameter in <GetMessage><GetPayload>. The description has them both doing the same thing. "Container for user-defined parameter to be made available to other Test Steps ( source can be this message's XML content retrieved via XPath statement or simply a user-supplied string value)".

[MIKE] - You are correct... they appear to do the same thing. I need to specify more clearly that <SetParameter> ( in the context of being a child of a <GetPayload> parent ) means to possible set a parameter value based upon the XPath evaluation of XML payload content. <SetParameter) ( in the context of being a child of a <GetMessage> parent ) means means to possible set a parameter value based upon the XPath evaluation of the XML message envelope content. In both cases, I propose moving <SetParameter> to a location "preceeding" <TestPreCondition> and <TestAssertion>, as I think that would make more sense. Also, I suggest moving <SetParamter> to a location preceeding <PutMessage> ( Test Framework Errata #5 and #6 )

3. Consider the possiblity of standard variables that can be used to cause the engine to generate a date-time value. For example:

TestDriverDateTime

                <SetParameter>
                    <Name>MyDateTimeVar</Name>
                    <Value>TestDriverDateTime</Value>
                <SetParameter>

This would cause the test driver to create a variable named " MyDateTimeVar". The value of the variable would be a date time value generated by the test driver.

If the name TestDriverDateTime doesn't isn't appealing, then maybe we could make it be more function like: test-driver-date-time()

Another useful example,

                <SetParameter>
                    <Name>MyGUID</Name>
                    <Value>TestDriverGUID</Value>
                <SetParameter>

[MIKE] - I support both of these. I will add this to the Errata. Any other possible "intrinsic" run-time variables you can think of?

4. For optimization, is is possible for the TestRequirement documents to refer to the TestSuite document that contains the necessary TestCases that fulfil the requirement? Right now it requires a disk search and file scanning to determine the correct test cases for a particular requirement. For optimization, and to avoid a disk lookup and file scanning, we have to specify in a database what requirement goes with what test case.

Profile -> requirement1

-> requirement2

requirement1 -> testsuite1/test case1

-> testsuite2/test case5

requirement2 -> testsuite1/testcase3

[MIKE] - We could do that.. I'll propose that in the Errata.

Regards,

Mike

ebxml-iic message