[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-iic-conform] MS Level 2 test reqs
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC