OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-iic] Resolution of issues during last conference call


Title: Call this Monday, and f-2-f at New Orleans
Mike: inline
-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Tuesday, February 10, 2004 2:39 PM
To: Jacques Durand; ebXML IIC - main list (E-mail) (E-mail)
Subject: [ebxml-iic] Resolution of issues during last conference call

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.
 

[Jacques Durand] OK for all previous. 

- 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>
 

[Jacques Durand]   So what could we have as arg of the "if"? woudl that be an XPath expression, like for Assertions? if we allow for such an expression, along with boolean ops, do we really need the "ifType" attribute?

- 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.
[Jacques Durand] For simplicity, I wouldn't deal with thread-level "view" of the store...how about:
- let us completely forget about the notion of thread when dealing with the message store: The store is specific to the test case, and all test steps - regardless of which thread they are in - will have same view of the store,
- Effect of a GetMessage step : it may "mask" (mask="true") messages it selected through its filter, and these messages will not be visible anymore to other test steps in the test case (from whatever thread). It may also "unmask" (mask="false") so what it selects is still accessible. Default is "true".
- from there, it is up to the test case writer to manage all side effects, e.g. via proper thread synchronization (join), and proper GetMessage filters, and proper masking.  
- PutMessage has no effect on the store.

- 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
[Jacques Durand] agree with that. Although in many cases where we (test case writer) have enough control on the test material we produce, this precondition wouldn't be needed, even if it was used in the "Test Requirement" script. In other words, just because there is a precond in a Test Req does not mean we have to use one in the Test Case. 
 
[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?
[Jacques Durand] why not, but it remains to be seen how reusable such a "thread" could be...So far I see that most test cases have specific test assertions, even if the sequence of test steps looks the same. 
Have we defined how "parmeterized" threads can be?
 
-----------------
 
 
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]