Minutes last meeting, next call

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: Minutes last meeting, next call

All:

Next call:

Time: Monday Apr 12, 2pm PT
Host: Fujitsu
Toll only :  1-512-225-3050
Participant code: 89772

We'll get another iteration of the spec by theend of thsi week and decide whether to submit it to vote
this Monday 12 (vote will be by email, over 1 week)
The new iteration should address the "notes" in the attached minutes.

Mike: can you especially check "note #2" and send a note to the list on current status for this?
we have to follow-up on this to make
sure that we have a clear scheme for terminating a test case (exit statement?)

Regards,

Jacques
<<IIC_April_05_04_minutes.txt>>

Time: Monday April 5, 2004, 2pm PT 
Host: Fujitsu 
Toll - : 1-512-225-3050 

Attendees:

Michael Kass (NIST)
Monica Martin (Sun)
Jacques Durand (Fujitsu)

Agenda: 

Review Test Framework specification, decide if ready for
submission to vote for Committee Draft. Specific Items to review are:

A- Script extensions
- filter-results notation. - Section 7.1.4.1 and Appendix D (schemas )
- split / join ops – Defined in section 7.1 table 9, section 7.1.1, table 10
- conditional ops, where used. – Section 7.1.8
- exception catching best practice – All tables in the spec
- timing of test steps, timeout vs "sleep". – Two different things completely , described as “stepDuration” section 7.1.3 table 11 and “Sleep”, section 7.1.8, table 32

B- Message store and getMessage semantics
- masking / unmasking the events that are selected. – Section 7.1.4.1
- scope of a store. – Not defined in spec
- time limit for a getMessage op – Defined as “stepDuration”, section 7.1.3, table 11

C-Parameters / variables
- how are they set.. Section 7.1.4.1
- pre-processing model, especially in filters – Section 7.1.3.1 ( for GetMessage )… but not defined for PutMessage

D- Interfaces
- assumed communication model. – Section 3.2.5, assumes an RPC communication model
- how ebMS-independent – Section 3.2.5 describes RPC communication model, ebMS independent..with SOAP binding example
- schema for message data. – Appendix F.. but needs to be explained in the specification text, also need to break apart RPC messages from Test Service ebXML messages ( i.e. make 2 separate schemas )

E- General execution model
- how do we execute an entire test suite. - No overall semantic definition of how a test suite executes. Just Test Case execution (section 7.1)
- possible outcomes for a test case, meaning for the test suite. – Section 7.1
- when a test has threads that don't join. – Not defined in spec
- best practices for Exception threads?
(e.g. verify we get either an Acceptance or a Reject, but not both?) No examples in spec. Suggest creating sample Test Case performing “if”, “then” , “else” to accomplish illustrate handling this particular test case ( since there is no “orJoin”)


-------------------------- minutes ---------------------------------


- Spec needs 1 more round of edits before being submitted
for vote next Monday 12.
In particular, following issues were discussed, need editorial treatment at least.
- Monica will verify the scripting capabilities for BPSS testing.

----- COmments on TFk 1.1:

Note 1: Section 7.1.4.1: A Test Driver should not be required to always store
teh entire message, expecially persisting attachments should be optional.
(A config item?)

Note 2: Section 7.1, line 1472: about the possible outcomes of a test case (fail, pass, undetermined)
We should avoid talking of "final leaf node" , as a Test Case may very well start concurrent threads,
that are not required to be joined (and therefore have several leaf nodes). 
In fact, even assuming there are steps after a TestAssertion, the latter should still be able
to terminate a Test Case. A general rule such as: 
"whenever a Test Step executes a TestAssertion, an Exit statement
may be associated with the TestAssertion result (either True or False). The Exit statement 
specifies the outcome of the test (either Pass or Fail or Undetermined). The first Exit statement
that is met during the Test Case execution, will determine the outcome of the test case."

Note 3: Section 3.3.1: replace "sequence" by "workflow" in the title.

Note 4: Section 7.1.3: shouldn't "Sleep" be an opeartion only allowed at test step level
and not everywhere?

Note 5: Section 7.1.8: Conditional statement: the spec needs be more explicit:
(a)- Either the "If" uses a regular, all-purpose condition like the one we use in Filters or TestAssertion.
Could it be a "TestAssertion" element? maybe. But in that case it does not need TestPrecondition.
(b)- Or the "If" always associated with a TestAssertion in a GetMessage element. In that case, it 
can indeed be associated either with PreCondition or TestAssertion. It could for example execute
an Exit statement.
It looks like we want (a) I believe.

Note 6: Section 7.1.4.1 and 7.1.3.1: These sections that talk about parameter setting should
be consolidated (or their parameter content be consolidated).

Note 7: Authors / Editor: should jsut be Mike Kass, all others are contributors.