[ebxml-iic] 9/25/2002: Durand Comments on New Test Material

[Monica Martin <mmartin@certivo.net>]

Regardless of the construction, we need to maintain some association
between the conditions that must occur to initiate the relevant event
associated with fulfilling the requirement.  Can we achieve that with a
flat structure and separate steps as opposed to conditions?  If we can,
the flat structure could apply.
 
Thanks.
Monica J. Martin
Program Manager
Drake Certivo, Inc.
208.585.5946

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: Monday, September 23, 2002 4:50 PM
To: 'Michael Kass'
Cc: 'ebxml-iic@lists.oasis-open.org'
Subject: [ebxml-iic] comments on new test material


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).
 
- 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). 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?) 
 
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