----- 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 -----