Re: [ebxml-iic] Proposed extension to include document processingin IIC framework

[Monica Martin <monica.martin@sun.com>]

Tim Sakach wrote:

>The proposal is to extend the <FileURI> semantics in <PutMessage><SetPayload>. If the file's extension is a stylesheet, then the test driver will obtain the stylesheet from the URI and transform a message in the MessageStore and then set the payload of the current PutMessage to the resulting xml.
>
><PutMessage>
>    <SetPayload>
>        <FileURI>Purchase2Confirmation.xsl</FileURI>
>    </SetPayload>
></PutMessage>
>
>
>Doing this would allow the test driver to create a response message that contains run time data, not static default data from base files. This would also eliminate the extensive use of <SetParameter> that would be needed to simulate the same behavior. Using static base xml files is still an option since the proposed change is an extension.
>  
>
mm1: I understand what you are trying to accomplish.  However, from a 
test perspective, I wonder what implications this has if the limited 
transformation (assume this with use of XSLT and/or XUpdate), we can 
verify conformance of the operations described in the test cases.  What 
if an error occurs?  Can we deterministically say that the conformance 
failed due to the ebMS or because there were errors in the 
transformation processing?  If this does not appear to be an issue, 
please advise and provide some explanation (This concern is primarily 
based on the need to localize where errors can occur and how we handle 
them).

> 
>Using stylesheets would also allow the test driver to create mutated and malformed response messages based on the incoming message. However, a <ModifyPayload> instruction with XUpdate support can also be added to the framework to accomplish the task of modifying a payload after it is has been imported.
>
mm1: Do we believe that XUpdate is stable enough to use? There were some 
discussions in another venue I saw recently bringing this into question 
(I don't have any specific knowledge/reference myself).  This function 
would however gives us the capability to create 'negative' test cases to 
increase the rigor of the test process (and automate what I have done in 
more large scale test projects). On <Use Parameter> would there ever be 
a case where we could have dependencies on the mutations that would need 
to occur? 

><PutMessage>
>    <SetPayload>
>        <FileURI>ConfirmationBase.xml</FileURI>
>    </SetPayload>
>    <ModifyPayload>
>        <XUpdate>xupdatemutationfile.xml</XUpdate>
>        <UseParameter>
>            <Name>MyParam</Name>
>            <Value>Xpath to change or static value</Value>
>        </UseParameter>
>    </ModiyPayload>
></PutMessage>
>
>
>The XUpdate or UseParameter operation would be performed after the SetPayload instruction.
>
>  
>