Re: [ebxml-iic] RE: Issues list: revised with new spec references

["Monica J. Martin" <Monica.Martin@Sun.COM>]

> Durand: >Any TestAssertion that evaluates to a result of "false", *and 
> from which no further >*
>
> * >workflow execution can occur * (i.e. no branching is possible) 
> based upon its boolean
>
>>result causes the Test Driver to cease execution of the Test Case, and 
> report a final result
>
>>of the Test Case as "fail".
>
mm1: I also found this confusing in reading the specification on the 
airplane on Saturday. Not to sound like a broken record, but we continue 
to expand the workflow capabilities when we could have used a defined 
one at the beginning. I am not sure we are gaining a great deal by 
trying to define new semantics for or-and that already exist.

> Even if we don't add explicit exits statements - agree we should avoid 
> them if we can -, I find the definition above a little shaky, and we 
> should try to make it better if we can:
>
> - what bothered me in this definition, is that it is 
> context-dependent: the interpretation of this step in a thread depends 
> on what is "around" the thread (here, what's after).
>
> [MIKE] – This is true. It will always be “context dependent” upon the 
> surrounding boolean logic. So not only does the <TestAssertion> 
> determine flow, but how that result “bubbles up” through the logic 
> tree will also ultimately determine whether a TestCase passes or 
> fails. Perhaps a little more definition can be added here.
>
> - Also, what if we always or-join all threads at the very end of a 
> test case, as a best scripting practice, with no other step behind? We 
> need to better define the "end" of a thread, or what "workflow 
> execution" means.
>
> [MIKE] – What about an “and-join”? Wouldn’t that be preferable? I 
> agree that a best practice for “hanging threads” would be desirable.
>
> A Test Writer can write XPath queries without the need to "negate" 
> their TestAssertion result externally.. If they wish to "negate" a 
> TestAssertion, they can do it within XPath with the XPath "not" 
> operator. For example:
>
> <TestAssertion>/FilterResult//eb:ErrorList</TestAssertion> (test for 
> the presence of the ErrorList element in FilterResult, return "true" 
> *if found*)
>
> <TestAssertion>/FilterResult//*[*not*(eb:ErrorList)]</TestAssertion> 
> (test for presence of the ErrorList element in FilterResult, return 
> "true" *if NOT found*)
>