[ebxml-iic-conform] MS Level 2 test reqs

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

Mike:

 

comments attached for Level 2-b.

No comments for latest Level 2-a.

 

So based on what we discussed this morning,

we could ignore the notion of "Level" in the Test Reqs,

and consolidate all into single Test Req file (still

preserving overall grouping per "spec module").

 

Jacques

 

 

 

r2.2.5:re-wording: 
[precondition]: the MSH allows for specifying maximum of received out-of-order 
messages, 
and this maximum has been reached for a given conv ID. 
[assertion]: REQUIRED: MSH notifies sending MSH with delivery failure (with 
code...). 

[MIKE] - Spec does not infer that allowing for a maximum # of out-of-order
messages is an option.. it infers that this is a requirement.. If it is an option,
then it should be specified as such.. therefore the [precondition] is not a 
condition at all, in my opinion. It is also not testable as a condition.
Reworded, but the condition is whether "max" unsequenced message count has been reached.

[Jacques]: you are right: I interpreted the "if" below as an implementation option:
"...If the implementation defined limit for saved out-of-sequence messages is reached, 
then the Receiving MSH MUST indicate a delivery failure to the Sending MSH with errorCode set
 to DeliveryFailure and severity set to Error (see section 4.1.5). ..."


r2.2.6a: re-wording: (consolidated with r2.2.7a) 
[precondition]: sending message with MessageOrder element, which is first for a 
conversation ID 
[assertion]: REQUIRED: the sequenceNumber element must have value 0, 
and its Status attribute = "Reset". 

[MIKE] - DONE


r2.2.7b: could be consolidated with r2.2.6b. 



[MIKE] - DONE ( also consolidated with r2.2.6a )


r2.2.8: (rewording) 
[precondition]: sending message with MessageOrder element, 
[assertion]: REQUIRED: the sequenceNumber element has Status attribute = "Reset" 
or "Continue". 


[MIKE] - DONE 


r2.2.9: not correct as stated: (sounded like reset *must* be done if 
precondition is true.) 
[precondition]: when sending message with MessageOrder element, and Status 
attribute = "Reset" 
[assertion]: REQUIRED: all previous messages for this conversation must have 
been accounted for 
(Acks received). 
(Note: can only partially be verified... as I believe the reset is controlled by 
the MSH, 
not the app) 


[MIKE- - DONE

r2.2.10: we could restate this using precondition: 
[precondition]: when sending message with MessageOrder element, 
[assertion]: REQUIRED: no SyncReply element is present. 

[MIKE] - This is covered in "merged" r2.2.2

[Jacques]: You are right. 

[precondition]: when sending message with SyncReply element, 
[assertion]: REQUIRED: no MessageOrder element is present. 

[MIKE] - DONE

[Jacques]: Is that one translated into r2.2.10.2 ? if yes, we should
not have "...AND No MessageOrder element is present " in the precondition,
as that should represent the Assertion of the test req.
In fact, These two test reqs: r2.2.10.1 and r2.2.10.2 are not well written,
as their assertion is automatically implied by their precondition, it seems.
I believe r2.2.10.1 is subsumed by r2.2.2, if it is same as my previous r2.2.10 above.

 

r2.2.11: "RECOMMENDED" instead of OPTIONAL ("should" in spec) 

[MIKE] - DONE

[Jacques]: I still see "OPTIONAL" in r2.2.11 assertion...(should be "RECOMMENDED")

r2.3: assume all these test reqs are moved to Level 3, review later... 

[MIKE] - DONE