[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-iic] 1.1 comments
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]