|
Mike:
Maybe
this debate is unnecessary: as long as we agree test case writers can do
"masking",
I'd
say the way it is done is implementation concerns.
So
overall, whether masked messages are actually removed - or just marked - is not
critical
for
the spec work I believe.
Note:
in all cases, we would probably need to keep a trace (log) of all received
messages for the test suite exec.
So your solution is fine.
I am adding a few more comments below to make
sure you understood mine...
Jacques
-----Original Message-----
From:
Michael Kass [mailto:michael.kass@nist.gov]
Sent: Friday, February 27,
2004 12:27 PM
To: Jacques Durand; ebXML IIC - main list (E-mail)
(E-mail)
Subject: Re: [ebxml-iic] edits for GetMessage()
op
If I do a <GetMessage
mask="true"> ( the default ) then any messages that contain a node in the
returned nodelist are "moved" to the "masked" MessageStore after the
<GetMessage> operation.
[Jacques Durand] The way I see it, we don't
need two message stores: we still always work with the original message
store. Only, I make the following implementation assumptions: (1) in the
message store, each message is numbered when added (e.g. M001, M002, M003
etc.) i.e. we add an identifier just for the sake of the message store
(there is already an Id in the schema, but we are talking here of something
different than the Id in the message header, probably would need to add
that to the store schema?). (2) When a Getmessage() is masking a
message, it just adds its store identifier in a list of "masked messages"
for this test case. (3) When a GetMessage() executes, it selects
messages that satisfy its Filter AND the identifier of which are not in the
masked list.
[MIKE2] - Here is perhaps where the problem
is. XPath processors only perform what is stated in the
query. In order to "add" this to a test writer's XPath query
(which can be expressed in a virtually infiniate number of ways) and
still make it "transparent" to the test writer... the Test Driver must
either:
a)Automatically modify the query to include
checking the <Message> element's "masked" attribute for value of
true/false.. (scary since the same XPath query can be expressed in a
virtually infinite number of ways.. and parsing and substituting
query text would be very difficult)
[Jacques
Durand] did
not want
that...
b) Have the test writer explicitly write their
XPath query (like below) to include a
@masked="true/false" since there is only one MessageStore,
containing both masked and unmasked messages, and the XPath processor
must be able to differentiate the two
types
/MessageStore[Message
@masked="true"//eb:MessageHeader/eb:MessageData[eb:ConversationId='123']]
[Jacques Durand] I
did not want that either... what I had in mind is that test cases
would still be scripted with "simple" XPath expression
in the Filter (without the mask test), and the Filter would be
processed by a stylesheet (XSLT) that would automatically verify
against the separate list of masked
messages.
c) Have the default be that all incoming
messages that match a particular <Filter> operation are actually
"removed" from the MessageStore ( that is the only way to
transparently "mask" them for a test writer...and an XPath
processor) This makes it transparent to the test writer,
and if they want to "save" messages that they've <Filter>ed, the
must specifically do a <GetMessage mask="false"/> to save them
for subsequent queries..
The one thing that a test writer would have
to be aware of ( if they wish to examine message content in a
subsequent <TestStep> or <Thread> ) is that they need to
explicitly set mask="false"
[MIKE2] - I agree that an XSLT processor could
easily modify an incoming message to add a "masked" attribute.
It's the modification of the incoming XPath query that is very
problematic. I'd opt to "remove" masked messages from the
MessageStore.. and keep life simple for XPath query writers.. and the
Test Driver...
[Jacques Durand] the option I had in
mind would not require this: XPath would not be modified. The
messages in store would not have "mask" attribute. The burden of the
mask check is on the xsl script. The only assumption is that a
GetMessage() Filter is always selecting Message
elements.
|