minutes, and next call

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

Title: minutes, and next call

All:

minutes attached.
Please see (and work on)the [AI] action items !

Jacques

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

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.
<<IIC_March_15_04_minutes.txt>>

IIC Conference Call Minutes: 
Time: Monday March 15, 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 R. (DrakeC)


Excused:
Pete Wenzel (SeeBeyond)
Serm (NIST)

Agenda: 

1. Test Case scripting: Status on remaining issues, summary of updates (Mike Kass, Jacques)
- review of recent issues.
- requirements for bus process testing (Tim): correlation issue.
- Current state of spec doc (content, status).


2. Test Framework interfaces:
- Status on standard, WSDL-based "astract" interface/API (Test Service - MSH.) 
(see Mike mail 3/5)
- 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:
- Mike just emailed latest copy of TFk spec, and the WSDL interface proposal.
- updated schema, threads. Introduced XSLT mutators.
- [AI] Tim will post an errata sheet about exec test cases (after feedback from Mike)
- [AI] Jacques will post latest updated draft from Mike on the site.
- draft is OK now about flow control, message store and GetMessage semantics.
- [AI] Needs refinement: (Mike) where will "run-time" vars be stored in message store.
What is their scope : just one tset case? global ?
- [AI] Needs refinement: Correlation between test steps of a same test case:
we'll have run-time variables, but where exactly can they be used: (1) in place of
values used in conditions within XPath filters (means that the var could be resolved
to its XPath expression over message store while filter still valid XPath itself)
(2) anywhere, meaning that the var has to be resolved to its actual value before
parsing the expression that contains it.
- [AI] Needs refinement: result of a filter needs schema: what should be the root node?
Also, filters should be restricted in their expression so that they cannot select
anything else than messages?
- [AI] Monica, Tim will send short informal use cases, on how such vars could be used
(BPSS context). Vars can be a convenience for parameterization of test case, or
a need for dynamic correlation (e.g. PutMessage, related to a previous GetMessage).
- [AI] Tim: we need to be able to trigger exec of the entire test suite, via the
Test Driver, not just a single test case at a time. Could this chaining be juust
a matter of design of teh test suite? How to pass / store the kick-off messages?
- we'll add names to contributor list of new spec (Tim, Laura)


2. Test Framework interfaces:
- So far, only interf Test Driver - Test Service is covered.
This mostly serves a three-nodes set-up for interop testing controlled by
a remote test center.
- basic "Receive" and "Send" calls = WSDL ops. Yet, the "message data" format
is not describe. If we want something generic, message-protocol independent,
we need to propose a schema (XML). E.g. Header attributes could be just listed
as name-value pairs, (XPath could be used for names, though not necessary).
- "Initiator" action uses SOAP format for message, the body contains messge decl.
- No ebMS dependncy so far BUT: message data passed by Test Driver to Test Service
should not be protocol-dependent... furthermore, the Test Service itself is not
supposed to know about ebMS format (behaves like an application to the MSH).
- [AI] do we have a protocol-neutral message representation (schema)?


3. Other:
- Korbit uses also a remote connection between MSH and Test Service.
Tim: should not be a problem, even if adds to communication.