Re: [ebxml-iic] 1.1 comments

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Michael Kass wrote:

> Jacques and all,
>  
>  
>    Here are my changes regarding your comments about v1.1 of the Test 
> Framework. I also changed the
> TestSuite schema to reflect a possible scripting syntax for branching 
> ( basically an IF (TestStep "clause"), ELSEIF (TestStep "clause"), ), 
> THEN (TestStep "clause"), ),
> ELSE (TestStep "clause"), )  construct.  "Clauses" are nothing more 
> than associative groupings of Test Steps, connected using an "AND" or 
> "OR" connective predicate.
> Comments ( particularly applicability to BPPS testing ) would be 
> appreciated.
>  
>   I'm rolling this up into a ZIP file for your review.    Please look 
> at the file:  IIC_ebXMLTestFramework_V1.1.doc as your reference.
> I'm cruising in Mexico all this week, and will return the day before 
> our next conference call. 
>  
> Have a great New Year everyone!
> Mike

mm1: Great job, Mike while everyone else is 'not working.' :-P
Anyway, here are a few comments from browsing the redline changes you 
have sent:


========================================================================================
Configuration Group
Table 3
Step delay may be handled on a conditional statement, where specific 
outcomes are required before a step continues. Suggest some sort of 
'choice' type so you can define what operation is made on the condition 
rather than assuming and/or. Perhaps we could have an enumeration of 
different types of which, one can be selected. See what is defined in 
ebBP, version 1.1. This comment applies to all such references. This 
brings up the point that a process language could be used to guide the 
execution of the test suite along the specific test cases composed as 
required to sufficiently implement this test. Are we willing to consider 
this as a future enhancement, or here in some fashion before we start to 
put branch semantics into the test framework itself?

Table 4
Assertion
Editorial - Reference should be generic, rather than targeted to MSH.

Table 7
On testStepContext, suggest you also use a generic type and allow for a 
choice from an enumerated list. That way, you can continue to add to the 
reference list.

Table 8
May wish to allow full or incremental purge of message store. This would 
suggest an attribute for full or partial and if partial how to designate 
what gets deleted. May
apply to later sections as well.

Table 9
Editorial - References should be generic rather than only listing MIME 
as more than MIME is allowed. May apply to latter sections.

Table 21
Allow for other optional mutator types - 'other' and then specify.

Appendix G Configuration Group Schema
Place 'other' as an option for contentType with the capability to 
specify, rather than direct reference to Schematron.

General
As we go later into the document, this becomes ebXML specific. Perhaps, 
these could become best practices, where use of ebXML, vanilla SOAP, 
etc. enveloping are detailed, but outside of the core framework 
specification.

Enjoy Mexico.  Monica