Mike:
Hope
these answers are useful...
-----Original Message-----
From: Michael Kass
[mailto:]
Sent: Wednesday, January 15, 2003
1:05 PM
To: Jacques Durand
Cc: '';
'';
''
Subject: RE: FW:
[ebxml-iic-interop] comments on Interop suite
Jacques,
More comments. Key
questions:
1) Need to assign <Manifest><Reference xlink:href
="abc"> at the application level in order to do any
meaningful payload
testing for interop, otherwise we have no way of fetching or evaluating a
particular
payload ( no CID to refer to ).
[Jacques
Durand] because we are at application level, we know that the MSH
provides us with an interface
(API, queuing, callback...) for:
(a)
when building a message to be sent, specifying the payloads we want to
send, and their names,
(b)
when receiving a message, getting a list of payload names, and content,
in some way.
The
way to do (a) and (b) may differ across MSH implementations, but given the
right adapter,
our
test driver can expect to always get/set this data, and in the current interop
set-up, will get/set it like if
it
were an application.
So I
think this allows for using your GetPaylod() op, just by using the
app-level "name" (not sure if we need
to
specify the "cid:" prefix) of the payload.
We
may assume that GetMessage() will provide the Test Driver with the list of
received payload names.
But
we don't even need this assumption as we know what payloads to expect when we
write test cases.
(does anyone see cases where that would not
work?)
2) Fold <SetPayload> operation into
<Manifest> declaration, and eliminate <SetPayload> as an
operation..
not needed, and it is cleaner.
[Jacques
Durand] I think the SetPayload op is still useful: It tells which payload
file to pick (e.g. a URI),
and
will associate with it the payload "name" we want to see in the message.
The Manifest alone can't do that.
In
putMessage(), When using Test Driver directly
at transport level, we need to define Manifest.
When
using it at application level, Manifest content will be actually determined by
the sequence of
SetPayload ops we do, by sender MSH. So its not important if we
don't mention it, but we can for consistency.
3) Define a
standard message payload format for including the digest(s) of payloads used
in the PayloadVerify
operation, consisting of a list of CIDs and their
corresponding Digest values.
[Jacques Durand] We could do
that. Note that in Test Service definitions, we were assuming that
payloadVerify
would compare received payload(s) with local copies of
the payload(s), and just send back a status message.
Drawback is, a copy of the payload(s) has to be pre-installed on each
party host before testing.
We
may assume that, in case there is no local copy to compare with, the status
message is replaced by a
"digest" message that lists the digest values (or signature) for
each received payload.
When
getting back this digest message, we would compare these
in
VerifyContent op with digest values created by putMessage() before sending to
payloadVerify() .
Is
that what you suggest? (any XML format in mind for this?
)
Attachment:
BIP_scripts_JD4.zip
Description: Binary data
