----- Original Message -----
Sent: Friday, September 26, 2003 1:19
PM
Subject: RE: [ebxml-iic] about 3.5 in
spec
Mike:
Front page should show right date, and also version
(and
it is called now a "Committee Draft" V0.95)
Comments mostly on the "parameters", which was the main remaining
issue:
---------------------------------
3.3.2: Message
content parameters -
Preceded with a '$' symbol, these parameters represent dynamic message content
used to both construct an ebXML message as well as evaluate returned message
conformance. These parameters and their description are listed in section
3.5.2.
>should
be : "...are listed in section 3.5.1"
[MIKE]
- Fixed
---------------------------------
3.3.2:
we need to say a word on the notion of "test step". We can reuse def
from Test Framework 3.3.1, e.g.:
"A
Test Case is a sequence of Test Steps. A Test Step is an aggregate of one or
more operations on the implementation under test. A Test Step usually involves
a single message sending or receiving operation, plus some data verification,
like checking or enforcing a condition on message header. A Test Step may also include
conditional actions that are a basis for the execution of the assertion within
the Test Step itself."
[MIKE] - Included appropriate
text
---------------------------------
About
parameters: we should get rid of $CPAId:
testcase_27.4:
"eb:CPAId=$CPAId
" , why not refer to one of our predefined CPAId ike in other test cases?
[MIKE] - I removed these
references
Same for 27.5 and other places. I guess we can do without
$CPAId.
[MIKE]
- Done
---------------------------------
Table
of parameters in 3.5.1 below need a few words about *when* these parameters
are set, as the expressions where they are used assume they are
set,
and
we should get rid of those that are unused.
CPAId (suggest to get rid of)
[MIKE] -
Done |
Reference to one of 13 MSH configuration
instances described in section
3.5.3 |
ConversationId |
As defined in [ebMS]. Represents the
ConversationId associated with a particular test case (will remain the
same for all test steps of the test case).
[MIKE] -
Done |
Service (not used here) |
For this abstract test suite:
urn:ebxml:iic:test
[MIKE] -
Done |
Action (not used here) |
As defined in [ebMS]
[MIKE] -
Done |
SenderParty
(instead of using a parameter, e.g. in test case
#90, can't we just directly refer to the From/PartyId element in the
received message? Same for multi-hop test
cases)
[MIKE] - I think that this would be more "convoluted and
confusing", plus it "breaks" the simple XPath notation rules for
defining messages. I feel that this attempt to "simplify" would in
fact make the XPath expression less understandable,and would argue to
keep $SenderParty in the XPath expression as an Abstract parameter that
refers to the PartyId of the
sender. |
The From/PartyId message
value |
ReceiverParty
(not used
here)
[MIKE] -
Agreed |
The To/PartyId message
value |
MessageId (we still have expressions with some of these left: I
thought we decided to get rid of
them)
[MIKE] - Tests 41,
43, 101, 134 (RefToMessageId tests) 182, 183, 184, 187,
188 and 193 (StatusResponse tests ) need to "know" the $MessageId of the
previously sent message to adequately test conformance, so $MessageId is
necessary for those tests I believe. |
As defined in
[ebMS] |
RefToMessageId
[MIKE] - I believe that we can eliminate this
parameter, and only use "MessageId' above. No need to have both,
since they refer to the same thing.
|
As defined in [ebMS]. Represents the message ID
value of the message that was manipulated in the previous test step,
e.g. of the latest message sent or
received. |
---------------------------------------
The
parameterized example in Sec 3.5.2 should not show parameters that are not
used in the test suite.
[MIKE] - Agreed
Regards,
Jacques
Jacques and all,
Please see my comments below.
Also, I've attached V0.95 based on comments below.
Regards,
Mike
----- Original Message -----