RE: [ebxml-iic] Minutes last meeting, next call

Jacques and all,

Here’s my comments re: meeting minutes. I will post an updated spec for possible vote

on Friday, based upon resolutions to these issues.

Regards,

Mike

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

[MIKE] Added this as a ConfigurationGroup 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."

[MIKE] – I agree that you may have multiple TestAssertion “leaf nodes” in the case of concurrent threads that

are not joined.. but why should that preclude me from failing the Test Case if any one of those TestAssertions fail?

Aren’t you testing the assertion for a reason? And if you’re not branching from there.. then failure of that TestAssertion

(which one assumes is important.. or you wouldn’t be testing it) should fail the Test Case.

And if an Exit statement MAY be associated with a TestAssertion, then that means it MAY NOT..

And if it may not.. then how do we make the final determination regarding the Test Case? The only way that

I can see to make an absolute determination of pass/fail for a Test Case is to assume that if a TestAssertion fails

anywhere, and there is no branching from it.. then the Test Case MUST fail. Forcing a test writer to provide a

“goto” (via an Exit statement) in a TestAssertion to assure that the Test Case ends properly seems like a heavy-handed

way to force the logic of the Test Case.. and forces the test writer to do this everywhere.

I can see the Exit Condition as an OPTIONAL “goto” that sets the final state of the Test Case and ends execution. But it

should not be used as the primary logic control for determining pass/fail of a Test Case… which means.. as the schema is now

written, a Test Driver will logically terminate the Test Case if it encounters a TestAssertion leaf node (whether it be single .. or one of many )

with a return result of “false/fail”.

Comments from implementers?

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

[MIKE] - Fixed

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

and not everywhere?

[MIKE] – Sleep is really an “instruction” not a Test Step operation per se… in order to make it a

Test Step.. we would have to give it a Test Step “context” ( CPAId, ConversationId, etc…. ) which seems

a bit heavy for a Test Driver instruction to simply “wait” for some period of time… Sleep can currently be used

anywhere, but I am not sure why that is a problem.. could be useful to sleep between Threads as well as

between Test Steps. Comments?

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.

[MIKE] – Currently, <If> can be followed by a <Thread> or a <TestStep> (i.e. if <Thread> result = true .. or if <TestStep> result = true )… then

do this <Thread> or do this <TestStep> else do this <Thread> or <TestStep> I do not see what is wrong with this logic.

You do not need to perform this at the <TestAssertion> level ( although we do and can ).. “Higher level” branching permits more of a

logical view for testing.. as opposed to an endless nesting within Test Steps. Comments from implementers?

(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).

[MIKE] – Will consolidate this

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

ebxml-iic message