OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic-conform message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

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

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


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


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) 


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. 


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


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC