RE: [ebxml-iic] call today...+ comments

Jacques,

My comments below [MIKE3] .. plus…

Here is the latest schema, with a few more suggestions for minimalizing scripting even more. Of note:

1) Rather than have a separate <SetPayload> operation, why not have a single “unified” <SetPart> operation, that can either construct a message envelope, or a message payload.. since they use exactly the same syntax already? I’ve attached a schema diagram illustrating the suggested changes.

2) Han Kim Ngo (our implementer here at NIST) pointed out that there may be situations where multiple <Split>s reference the same <Thread> , and that the Test Driver would now know which one is referenced in the corresponding <Join>.. therefore we recommend an “instanceId” attribute for each <Thread> that is <Split>..so that <Join>s refer to the appropriate <Thread>.

e.g.

<Split>

</Split>

….

…

<Split>

</Split>

…

<Join>

</Join>

Comments?

Mike

-----Original Message-----
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Monday, June 21, 2004 11:44 AM
To: ebXML IIC - main list (E-mail) (E-mail)
Subject: [ebxml-iic] 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).

[MIKE] – One way to do that is to have the Test Driver simply “infer” that, if a <Mutator> element is not present in the script, then the Test Driver must interpret the <Declaration>, and use its API to generate the message (i.e. not rely on an XSL or Xupdate engine to create the message).

Role of XSLT.
- discussion on few remaining points (see below)
- BPSS requirements: are we OK?

[MIKE3] – The latest use case examples I believe satisfy those particular use cases. I do not think that we have adequately examined BPSS requirements yet unless we begin with a “base” BPSS instance document and parse/transform it into Test Cases. I believe that a basic “Test Service” like that used for MS testing would help us do conformance testing on a BSI.

- looping cases: =recursive split? (conditioned by an Assertion)

[MIKE3] – We’ve addressed this in the test framework schema. Please see the attached schema diagram, illustrating a recursive split based upon a <TestAssertion> boolean result.

2. Test Framework 1.1 spec:

- levels of conformance, if any?

[MIKE3] – This is not something normally found in a Test Framework specification. I think however, that it should be clearly stated what components are necessary for a particular type of testing. There are certainly optional features of the Test Framework that someone does not need to implement if they are never going to use them. For example, Registry testing will never require the implementation of a Test Service at all. A2A conformance testing also does not need to implement a Test Service.

Also, an implementer may use Xupdate as their <Mutator> instead of XSLT in their Test Driver. Implementation of only one of these technologies will preclude the use of test suites using the other. This should be clearly stated in the specification.

Perhaps we should add a section describing a matrix of what components and technologies are needed for the different types of testing.

- any "binding" to consider? (optional, but normative)

[MIKE3] – We currently have an optional SOAP binding specified for RPC operations (initiator, notify ). Because there are many packages for messaging, specifying a normative binding for a message may be difficult. But if we do specify them , I believe they should be a normative part of the appendix.

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.

[MIKE3] – OK. Will do that.

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

[MIKE3] – I modified the script so that if //*[ErrorList] is found in the <Filter> the Test Case fails on this condition any time within the 300 second StepDuration. The Test Driver will continue to poll on the Message Store until 300 seconds has completed or it matches the XPath <Filter>… So this will accomplish the same thing as a <Sleep>… but yes a <Sleep> could be used as well. But using stepDuration is more efficient.. since you don’t have to idly wait 300 seconds… Please see latest for test use case #2

the thread proceeds, and completes on "continue",
(e.g. after 200sec) ignoring an error message that arrives at 250sec.

[MIKE3] – This would work as well

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

[MIKE3]- We’ve modified the schema to have a <Header> element that can be any name/value MIME header pair. This would allow API level manipulation of message content for MIME.

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

[MIKE3] – We could.. but it really doesn’t save us anything. In fact, it is more limiting in what types of characters are permitted for “value”.

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

[MIKE] – Perhaps I should change the name from MessageHeader. In fact we did that, and simply call it <Header>. I don’t want to call it <MimeHeader> since that is so implementation specific.. but that is what we are talking about. A <Header> is a generic attribute to be assigned to a message envelope… or a message payload.

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

ebxml-iic message