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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

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


Subject: Re: [ebxml-iic] definitions


Title: definitions
Jacques,
 
 I just have on comment below.
 
 I agree with the idead of updating the ebXML Test Framework and Conformance Test Suite documents to add this information.
There are a few other editing jobs needed on the Test Framework document, so I suggest we have an "edit review"
in which we gather any and all changes we propose prior to a vote, to minimize the need to call multiple votes.
 
 And for the the next version of the Test Framework document, we need to begin compiling  a list of proposed changes and additions
that need to be made.
 
Regards,
Mike
 
----- Original Message -----
Sent: Wednesday, August 27, 2003 5:47 PM
Subject: [ebxml-iic] definitions


OK, here is attached an update version based on Mike/Monica comments.
If we agree, we should insert into the Conf spec, and also candidate for the next TestFramework update.


>[MIKE] - Following Monica's thread, I think that we should identify
>assertions in the conformance testing requirements
>that we recognize as "implementation guidelines", since in fact the ebMS
>specification
>is full of them.   For example, "storing a message in its entirety in
>persistent store" is one
>assertion that falls in the implemtation guideline category.  I believe that
>any test requirement identified as an
>implementation guideline should NOT have an abstract test case.

Definitely. But I can't think of many such cases in ebMS.
maybe some SHOULD fall into this class...

 

[MIKE] - I agree that there are not too many, but they should be identified, and not

described in an abstract test case if they are determined to be implementation guidelines.

>If, however we recognize
>a test requirement as being a valid conformance test requirement, but we
>cannot write a test case for it because of constraints
>on our test framework, then we SHOULD write an abstract test case for it
>(e.g. MSH interrupts and
>restarts ).  I think that this approach would give us a consistent test
>requirements (and test suite) document.

Absolutely. Our definitions of abstract / executable show this is possible.

Jacques
<<Test_Req-Abstract-Concrete.txt>>


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgroup.php.


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