Re: [ebxml-iic] 1.1 comments

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

> Durand: - On the Errata sheet, item #6:
> I am still uncomfortable with dissociating COnfigurationGroup from
> the test suite element: how can we enforce the association of a test 
> suite and of a particular CPA?
> I understand this association is not always desired, but i other cases 
> we want to be more prescriptive
> and describe the config(s) that make sense for this suite.
>

mm1: Comments on Errata document:
Scripting Parameters
Several scripting parameters seem to indicate that something can be 
customized, which is inline with our discussions today -  distinguish 
implementation from the specification of the framework. This brings up 
the question whether or not an entity may or may not allow 
specialization. For example, an industry may not allow test suite to 
change the message structure or context because it defines an 
enumeration set or has a fixed set of minimum required elements. It may 
wish to enforce that rigor on any testing of a constrained structure. Do 
we need some overall flag that allows some of this specialization or 
not, or just assume maximum flexibility? Is this part of the 
configuration group?

#12 Can we get more details on Block and Release test operations 
specified by Woo? This looks like constraints on use of synch/asynch (?).

General
Separating the communication between the Test Driver<-->Test Service may 
help isolate what happens in the test (exercising of requirements) vs. 
what happens to support the test (communication between test driver and 
service). However, I believe the lines will get quite gray as we move 
into business process territory.

#13 Branching
Should support the minimum seen in BPSS:
1. either/or
2. and
3. concurrency (back to a particular join)
4. parallel (exceptions and message response, for example) where they 
both are valid
to start.....

This brings up two interesting points about nesting which we could see 
in BPSS where we may not be able to avoid the compositional aspects of 
the testing we discussed in 12/22 call:
a. with compound binary collaborations
b. with the possibility of composition based on other than dependencies
 b-1 differentiate outer-inner from outer handoff to inner and an inner 
that is then independent [1]

[1] May equate to a pre-condition that must be true before another 
activity starts. This is beginning to look like another ebXML set of 
specifications. :>)

#16 Does this nesting of test requirements within test requirements also 
speak of implementation or test suite functionality not of our 
specification?  Where do we draw the line on 'packaging'? We can provide 
maximum flexibility but need to still some rigor in our framework. I see 
value in allowing the capability of associating a given set of 
functional and test requirements [2].

[2] Note, this could be M-M, which gets back to my packaging question.

#23 Plug-ins
I would encourage you to allow an 'any' type contentType and allow 
user-defined specification. I am still concerned about any reference to 
a vendor-specific tool.
If we allow the user-defined abstraction, Schematron could be a best 
practice defined and held in a separate guideline outside of the 
specifications.

#24 and #25 Payload Integrity
Do we lose any community if we don't allow another 'any' selection for 
other than XMLDSIG? See suggestion in #23.

#26 Remote Test Driver
I can understand the concern that you want to separate pre-test 
configuration from test execution. How this is accomplished is an 
implementation detail IMHO, although we should allow its specification. 
Same comment on #29.

#27 Errors
This might be difficult because we get closer and closer to binding to 
applications, as we define these errors. And too, when we do BPSS, you 
have exceptions that may result in errors (in messaging).  See 
suggestion in #23.  I would indicate what errors may occur between the 
test driver and service exclusively (not as a by-product of the testing 
itself but between the test component infrastructure).

#30 API Definitions
Need more information on #30 API request. Can see need for #31 as it is 
an important part of the test framework functionality, although 
uncertain with #30.  Should
there be a minimum set of guidelines to provide some structure around an 
API without implementing it? Borders on our implementation / design 
discussion 12/22.