[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Kass [ebxml-iic] 9/27/2002: Comments on Test Material...from 9/25
See my comments inline. Thanks, Mike. Monica -----Original Message----- From: Michael Kass [mailto:michael.kass@nist.gov] Sent: Wednesday, September 25, 2002 12:32 PM To: Jacques Durand Cc: 'ebxml-iic@lists.oasis-open.org' Subject: [ebxml-iic] Re: comments on new test material Jacques, Please see my comments below At 03:50 PM 9/23/2002 -0700, Jacques Durand wrote: Mike: I like the new test material upgrades definitely better...Some comments on your latest draft of MS Test Cases: - we need also to set the CPAId of messages we generate: that would set the CPA that should govern each test case. (the new "$CPA_xyz" parameters would allow to use elements of such referenced CPAs, in "Conditions) - The new operation "Condition" should only include logical conditions and relational operators (<,>,==,!=), not assignments (=) like the XPAth expr used to prepare a message to be sent out (for a PutMessage). So these assignments could be left as arguments of the PutMessage op (in its "message expression" field) like they were before. - just a matter of format: The arguments for SetPayload, (Content-Type =..., COntent-Id =...) should be treated like any other "message expressions" (so should be in this field, like the XPath expressions). [MIKE] - Agreed and done. See latest attachment - The semantics of the Condition attached to a GetMessage op, is one of a filter (that typically selects a message based on COnversationID and RefToMessageId, to actually decide whether or not to pick an incoming message, as further test material.) It is different than other COnditions, which only work on message material already in store, from past steps. For this reason, I'd keep the "filter" conditions in "message Expressions" of the GetMessage op itself (i.e. they are "parameters" of GetMessage, as they help do the selection). [MIKE] - Agreed.. I'd go a step further and suggest that we assume a standard "filter of CPAId, ConversationId and MessageId.. and not even write out the filter statement for <GetMessage>.. this more likely will fit the ultimate implementation XML of: <GetMessage cpaId="abc" conversationId='def' messageId='ghi'> <Condition>.....</Condition> <!-- this only applies to real condition/conformance test filtering --> <Condition>..</Condition> <!-- this only applies to real condition/conformance test filtering --> </GetMessage> [Monica Martin] Yes. It will also simplify the look of the abstract tests. Comments? For some other "Condition" operations, (like the ones on "optional" material, or the ones used for final verification) we could dissociate them from GetMessage and make them really separate ops (or steps)... (Should we "flatten" our steps, and have roughly each one of your table row correspond to a step - after Get and Put have their related expressions - message builders and filters - back in their "message expr" fields?) [MIKE] - My concern with flattening has to do with associating <Condition>s with a particular <GetMessage>... The way things are currently defined we have: <TestCase> <Step> <PutMessage/> </Step> <Step> <GetMessage> <Condition1/> <Condition2/> </GetMessage> </TestCase> You are suggesting: <TestCase> <Step> <PutMessage/> </Step> <Step>GetMessage></Step> <Step> <Condition1/> </Step> <Step> <Condition2/> </Step> </TestCase> By flattening. it appears that you lose the containership "parent/child" relationship between a <GetMessage> a particular message, and all of the <Condition> filters associated with it. Everything's a step, with no association between the steps. That is why XML containership is important, in my opinion. Even though we are describing this in an "abstract" sense, there are some real-world consequences if we do not adequately describe the relationships between our test components. When we code the test driver, this will be important. Tables like the one we are using for describing the Abstract Tests are not well suited to represent containership. I represent that containership through the use of the Step # column, with the only steps defined as either a <SetMessage> or <GetMessage>. Using object oriented principles, these <Steps> could return any number of exceptions, depending on which object generates a which type of a fatal exception. Looking at this now, I would probably go a step further and using object oriented design, change the Condition class to be <TestCondition> or <Condition>.. one throws a "fatalTest" exception, the other a "fatalPrecondition" exception... rather than having to create an attribute called "errorStatus" that the test writer must assign a value. So we would have as potential classes: <SetMesssage> <GetMessage> <TestCondition> <Condition> <SetPayload> <GetPayload> [Monica Martin] I agree with Mike. These containership discussions have been going on in UBL and they have been trying to show how structure should be placed into the physical model (the XML syntax). I also like the condition suggestion (as I said before differentiate so you can reuse). My feeling is, even though we are describing "abstract" tests, we should consider the implementation consequences of how we are describing these tests. I will respond to your other comments separately, within the associated mail message. Thanks, Mike Regards, Jacques -----Original Message----- From: Michael Kass [ mailto:michael.kass@nist.gov <mailto:michael.kass@nist.gov> ] Sent: Monday, September 23, 2002 9:40 AM To: Jacques Durand; 'ebxml-iic@lists.oasis-open.org' Cc: michael.kass@nist.gov Subject: Re: [ebxml-iic] IIC Conf Call Monday,Sept 23th at 10:00AM , and more To all, Here is the latest revision of the ebXML MS Abstract Test Suite, based upon discussion this week. Main changes are: 1) Addition of all "mini-cpa" parameters into name/value pairs for pass-through to Test Message Expression filters 2) Introduction of "Condition" element to represent filters to either construct or examine message content 3) Addition of "errorStatus" attribute.. to be applied to any element <PutMessage>, <GetMessage>, <SetPayload>, <GetPayload>, <Condition> The default for all is "fatalPreCondition".. for all element. Any element that is a verification step requires an errorStatus = "fatalTest" value. I only got through the first 15 Test Cases with this new format. Will finish the remainder this evening after our phone conference. Regards, Mike
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC