Resolution of issues during last conference call

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

Title: Call this Monday, and f-2-f at New Orleans

Jacques and all,

 

  Here is my synopsis of the issues discussed in yesterday's call.   I am beginning modification

of the test framework specification based upon these resolutions.  Please let me know if I

have correctly captured them.

 

Thanks,

Mike

 

 

 

 

- "sleep" step

 

[MIKE] - Added a <Sleep> operator to the scripting schema.  <Sleep> can be place anywhere

in the scripting ( before <TestStep>s or before <Thread>s )

 

- split/join, final position

 

[MIKE] -

 

Asynchronous <Thread>s will only be defined inside of a <Split>  ( agreed to by Jacques ).

Also,  <Split> may have a <Join> operator with an attribue of joinType= "andJoin" or "orJoin"

- if-then-else: where usable 

 

[MIKE] - <If><Then><Else> can be inserted anywhere within a <Thread>.   The construct is:

 

<If ifType="andIf/orIf">

...

...

...

<Then>

...

...

<ElseIf ifType="andIf/orIf">

...

...

<Then>

...

</ElseIf>

<Else>

...

..

</Else>

</If>

 

- management of the message store, semantics of putting and getting messages.

 

[MIKE] - This was not thoroughly disccuess on the conference call due to time limitation.s

Agreed that "deletion" of messages was likley to cause side-effects in a message store when

concurrent <Thread>s are accessing the same messagestore and that an optional "masking"

of a message store ( perhaps at the <Thread> level ( i.e. having a new "virtual" message store,

local to that<Thread> whose lifecycle is the duration of that <Thread>.  Incoming messages would

go  to that <Thread>'s local message store, but would also be placed in the "global" messagestore. 

<GetMessage> operations within that <Thread> would only have access to the local message

store.  Comments?  If this is an agreeable approach, then I can update the message store semantics

in the test framework specification.

- test case exit values: "pass/fail/notapplicable"? Exit statements.

 

[MIKE] - Agreed during the conference call that the "true" result of a

<TestAssertion> could optionally contain an exitCondition attribute whose value

may be "pass", "fail" or "not applicable".

 

- the PreCondition role in GetMessage.

 

[MIKE] - We discussed this in the ongoing mail thread, with ( I believe ) the agreement

that the test writer does not necessarily have control of all testing preconditions

(e.g. a candidate MSH may send its messagesa as "multipart/related" or "text/xml"...

so a <TestPrecondition> is necessary so as not to fail a <TestCase> because an optional

features was not implemented

 

[MIKE] - Other issues include:

 

Global Threads - <Thread>s defined at the <TestSuite> level.. Useful for such things as

global "exit" operations, or often used sets of <TestStep>s that vary only with the

<ConversationId> or <Timestamp> values.  I suggest adding a global <ThreadGroup> at the

<TestSuite> level to permit definition of such global <Thread>s.  Comments?