1_1 comments - part 2

["Michael Kass" <michael.kass@nist.gov>]

Monica,

 

   Here is my response to your next post re: Test Framework v1.1 Specification changes:

 

Thanks,

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?

 

 

[MIKE] - I don't know if a BP language would be suitable for a Test Driver, or would

be more than is necessary.  BPSS use cases could help determine this.

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

 

[MIKE] - Agreed and fixed.

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.

 

[MIKE] - It was also suggested that all Test Steps be given an ID, and that testStepContext

could reference the ID ( and context ) that is needed for a particular Test Step.  I

updated the schema and spec to reflect this

 

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.

 

[MIKE] - I am rethinking whether  this is an implementation detail ( regarding when the message store is purged.. if at all )

This is really a "performance/optimization issue", and I think that this attribute may not belong in this specification. 

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

 

 

[MIKE] - This is true, and the modifications that we are doing to this specification are designed to "open" it to any kind of

messaging.  However, this specification also provides instructions "specific" to ebXML Message Declaration syntax

explicitly for constructing ebXML messages using MIME.  If it were more complete, it would also provide a Message Declaration Syntax

for SMTP and FTP messaging, but we do not provide that.  We need to point out that MIME declaration syntax is a

best practice when constructing MIME messages with the Test Framework.

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

 

[MIKE] - We could do this.

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

 

[MIKE] - This was a typo. Schematron should not have been listed in that enumeration group.  Fixed

 

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.

[MIKE] - Agreed that it is not clear that any ebXML, MIME, SOAP etc information should be labeled as

best practices rather than hard specification.  Especiallly since the spec (V2) is being written specifically to allow

any transport and envelope to be used.

 

Enjoy Mexico.  Monica