[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.
[MIKE3] -
Understood
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.
[MIKE3] - This is fine. Although we don't have to
specify that XSL is used to "post-process" the returned node-list of
Message elements... this can be an implementation detail ( some
folks may just use DOM to do it ). I'll update the GetMessage
documentatio to reflect this.