ebxml-iic message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ebxml-iic] comments on new test material
- From: Jacques Durand <JDurand@fsw.fujitsu.com>
- To: 'Michael Kass' <michael.kass@nist.gov>
- Date: Mon, 23 Sep 2002 15:50:13 -0700
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
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