[ebxml-iic] Re: comments on new test material

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

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>



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>

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]

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

Attachment: ebxml_ms_20_abstract_tests.doc
Description: MS-Word document