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