Minutes and next call April 5th

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

Title: Minutes and next call April 5th

All:

1. Minutes March 22 attached.

2 Next call:
Time: Monday April 5, 2004, 2pm PT
Host: Fujitsu
Toll - : 1-512-225-3050
Passcode: 89772#
See agenda below, with points to look at...

3. Mike, in order to help people focus on the new features, can you
associate section numbers with each of the features I have listed inthe agenda below? (under A,B,C,D,E)

4. Normally, we should put the spec to vote as Committee Draft by this Monday,
for a 1-week vote period (vote ending April 12).
But if we identify serious-enough issues that need be fixed, what we'll vote on is the
decision to start the vote as soon as a new draft that addresses these issues is released.
This means, some updates may be requested at Monday review,
that will take a couple of days to address, so the new draft is posted on Wednesday,
and the chair will declare the vote open starting Wednesday (for 1 week).

There might also be some non-normative additions (e.g. examples, best practices)
that could be voted later.

Jacques

------------ Agenda April 5th:

1. Review of latest Test Framework draft posted by Mike (Tuesday 3/30)
In particular, we'll review the following points (even if they are settled by now,
their editorial treatment needs review and comments !)
If review overall OK (no major flaw uncovered) I'll put the spec
to vote (email), else we may vote on a list of issues to be addressed
by the editor, and starting the vote as soon as a new draft is posted.

Please be ready to express feedback on:

A- Script extensions
- filter-results notation.
- split / join ops
- conditional ops, where used.
- exception catching best practice
- timing of test steps, timeout vs "sleep".

B- Message store and getMessage semantics
- masking / unmasking the events that are selected.
- scope of a store.
- time limit for a getMessage op

C-Parameters / variables
- how are they set.
- pre-processing model, especially in filters

D- Interfaces
- assumed communication model.
- how ebMS-independent
- schema for message data.

E- General execution model
- how do we execute an entire test suite.
- possible outcomes for a test case, meaning for the test suite.
- when a test has threads that don't join.
- best practices for Exception threads?
(e.g. verify we get either an Acceptance or a Reject, but not both?)

<<IIC_March_22_04_minutes.txt>>

IIC Conference Call Minutes: 
Time: Monday March 22, 2004, 2pm PT
Host: Fujitsu
Toll - : 1-512-225-3050
Passcode: 89772# 

Attendance:

Mike Kass (NIST)
Jacques Durand (Fujitsu)
Monica Martin (Sun)
Steve Yung (Sun)
Tim Sakach (DrakeC)
Michael Rogan (DrakeC)
Pete Wenzel (SeeBeyond)

Excused:
Serm (NIST)

Agenda: 

1. Test Case scripting: Status on remaining issues, summary of updates (Mike Kass, Jacques) 
- Run-time vars, scope and storage. 
- filter results. 
- kick-off the entire suite with one shot. 
- requirements for bus process testing (Tim): use of vars, correlation. 
- Current state of spec doc (content, status). 

2. Test Framework interfaces: 
- Review of WSDL-based "astract" interface/API (Test Service - MSH.) 
- Can we settle on an envelope-agnostic "message wrapper" document 
(header fields + payloads) 

3. Other: 
- Test harness architectures: the Korbit case for remote conf testing. 
- Update on ETSI European test event, Korbit remote conf testing, search for pre-testing 
candidates. 

------------------------------------------------
1. Test Case scripting: Status on remaining issues:

- Run-time vars, scope and storage: 
- Mike: parameters are passed to the getMessage op.
Their value will be substituted in teh filter expre, before the parsingof XPath.
- Variables must be usable more genrally outside getMessage ops: e.g. for generating
dynamically permutations of values for attributes.
- Monica: RegRep uses $param for added flexibility.
- Tim: vars are associated with 1 instance of test run. It does not matter
if they are persisted within the store or not.
- Are variables values only determined from message input? 
No, we 'll have set param ops. 
We can have "session" variables, set after initial config data. 

- filter results: added a root element for filter results, holding a subset 
of stored messages.

- Test Case Exceptions: either malformed XPath expressions, or network problems 
like no HTTP response. Such exceptions will yield 

- kick-off the entire suite with one shot? Not so critical. As long as there
is a way to trigger the execution of the entire test suite, it does not
matter. E.g. if we use a script that will trigger one by one each test case.
However, if the test driver executes such a script, it would need to serialize
properly each test case (although, technically, if the correlations are well done
concurrency should not cause much problem! E.g. some test cases may take a long
time, and we could accept a reasonable level of concurrency).

- Errata from Laura B. has been added.
- Monica has examples from ebBP material. Will send out.
- Mike consolidated list of suggestions from Tim, for the Executable test suite.

2. Test Framework interfaces: 
- Jacques: the role of interfaces is to help portability of test framework
components, e.g. Test Driver from vendor A used remotely with Test Service from
Vendor B. It would have also helped to propose an interface Test Service - MSH,
because that would make the "wrapper code" that MSH vendors have to write,
less dependent on test framework implementations.
- A WSDL interface? Mike: What we proposed is rather a SOAP interface, 
between TDriver and TService.
- Monica: how normative? if this is optional, we should make it RECOMMENDED.
- Message declaration + payload are packaged in a neutral format.
- Jacques: not only the commmunication Test Driver - test service should
not show any ebMS format, but the communication Test Service - MSH should
not either. The Test Service simulates an app, should NOT have to know anything
about ebMS header syntax, which is the job of the MSH to craft.
Same thing for returned messages: should not have to be parsed by TService.

3. Other:
- We'd liek to get feedback from Korbit on the test framework 1.1. 
But they seem to be very busy with ETSI test preparation.
- Jacques will ask Dr. Cho.
- ETSI testing round has been advertised.
 http://www.etsi.org/plugtests/ebXML.htm 
we follow this and act as a resource for them: this is the first time the test framework
will be used in real testing (both conf and interop). Korbit does the conformance part.