call today...+ comments

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

Title: call today...+ comments

Next call:
Time: Monday June 21, 2004, 2pm PT
Host: Fujitsu
Toll only : 1-512-225-3050
Participant code: 716071
NOTE: I may experience some difficulty doing this call, as traveling and at that time
I have limited access to a phone. However, the bridge willbe activated even without
me initiating it. If I can't make the call, feel free to use the bridge for informal
talks...

Agenda:

1. Test Framework 1.1 technical:
- wrap-up the approach we use to message building:
in case we want to use Test Driver to drive a message interface
at "application-level" (e.g. a JMS provider, or a WS client), can we? (we'll have to
say how in spec). Role of XSLT.
- discussion on few remaining points (see below)
- BPSS requirements: are we OK?
- looping cases: =recursive split? (conditioned by an Assertion)

2. Test Framework 1.1 spec:
- levels of conformance, if any?
- any "binding" to consider? (optional, but normative)

Jacques

---------------

SOme comments on previous mail (use case #2, #3):

[MIKE]  We use <WhenTrue><Split><ThreadRef="thread_02"/></Split</WhenTrue>
[JD]: that is fine to me.

[MIKE] - I was trying to follow the semantics of workflow, however if you are saying that we can simply have a <Thread> without having to enclose it in a <Split>, that would be fine (i.e. it would be considered a "synchronous" execution of a <Thread> by default.

[JD]: I wouldn't give it any different semantics than the embedded form...
Synchronous with main (invoking) thread would be achieved by:
<Split>... threadref= ABC </Split>
<join> threadref= ABC </join>
(so main thread will wait end of ABC to proceed further steps)
But we don't have to "join" right after, in which case main thread would proceed
concurrently with ABC.

thread_02 needs to wait 300sec before doing the check.
[MIKE] - Actually, just having a "stepDuration=300 for the <GetMessage> will accomplish what we need, without having to <Sleep>  (see updated use case example)

[JD]: Not here Mike: remember that there is a subtle difference between (a) sleep(300) and (b) stepDuration=300. In (a), the error thread will catch everything that will have occurred

within the 300 sec (will make sure no error message occurred). In (b), as soon as the GetMessage
filter is satisfied (//*[not(eb:ErrorList...), the thread proceeds, and completes on "continue",
(e.g. after 200sec) ignoring an error message that arrives at 250sec.

[MIKE2] - Actually, we can generate "erroneous" messages using a MIME API as well (supplying erroneous MIME header content).

[JD]: OK, these would be "well-formed" errors. That will be sufficient in many
cases. But generally, I assume the scripting will
allow for full manipulation of MIME envelope - sometimes this is useful to avoid MIME-package-dependent idiosyncrasies (correct way to use MIME, but limited)

[MIKE] (example below)
JD: questions:
- instead of using a MessageHeader element for each name/value pair:
can we wrap all pairs in a single element? (e.g. by putting "value" as an attribute of "Name")
- how do these MessageHeader elements relate to the MessageDeclaration element content?
- what is the semantics of adding (repeating?) MessageHeader element in the SetPayload element?
that does not seem to belong to the final message (e.g. ebXML) header, but to some MIME headers.
<PutMessage>
<MessageHeader>
<Name>Content-Id</Name>
<Value>cid:MessageEnvelope</Value>
</MessageHeader>
<MessageHeader>
<Name>type</Name>
<Value>text/xml</Value>
</MessageHeader>
<MessageDeclaration>
<soap:Envelope>
<soap:Header>
<eb:MessageHeader>.....</ebMessageHeader>
</soap:Header>
</soap:Envelope>
</MessageDeclaration>
<SetPayload>
<MessageHeader>
<Name>Content-Id</Name>
<Value>cid:PurchaseOrder</Value>
</MessageHeader>
<PayloadDeclaration>
<rn:PurchaseOrder>
</rn:PurchaseOrder>
</PayloadDeclaration>
</SetPayload>