[ebxml-iic-framework] Re-ordering precedence rules

Jacques,

    I had the order reversed on rule precedence for the Config parameters. 
Here is the correct selection rules for the Test Driver.  The logic is:

For "non-driver mode" ( stand-alone Test Driver)

If someone explicitly declares any of these values in the actual XML 
PutMessage declaration, then that value should be used by the Test Driver 
to construct
the message.
If the value is not in the PutMessage declaration, then the Configuration 
Parameter, if present is used to assign the value.
For parameters that are "auto-generated" by the Test Driver ( e.g. 
Timestamp ), if there is no XML declaration, and no Config parameter value 
set, then the Test Driver  "auto-generated" value is used.
For parameters that are also present in the CPPA ( SenderParty and 
ReceiverParty) , an explicit XML PutMessage declaration takes 
precedence.  If an XML message declaration is not present, then if a Config 
parameter is present, it is used.  If neither a message declaration nor a 
Config parameter is set, the the CPPA value is used.

The table below illustrates this:

Parameter Name	CPPA Equivalent				Precedence1			Precedence2		Precedence3
------------------------ 
-------------------------				-------------------			------------------- 
-------------------
$SenderParty		<tp:PartyInfo><tp:PartyId/></tp:PartyInfo>	XML PutMessage 
Declaration	Config Param		CPPA
$ReceiverParty	<tp:PartyInfo><PartyId/></tp:PartyInfo>		XML PutMessage 
Declaration	Config Param		CPPA
$CPA (Id)								XML PutMessage Declaration	Config Param
$ConversationId							XML PutMessage Declaration	Config Param		Test Driver 
auto-generates
$Action								XML PutMessage Declaration	Config Param		
$MessageId								XML PutMessage Declaration	Config Param		Test Driver 
auto-generates
$Timestamp								XML PutMessage Declaration	Config Param		Test Driver 
auto-generates


For "driver mode" ( Test Driver coupled with MSH ) the same rules as above 
would hold, however the Test Driver may not be able to set these values 
through the MSH interface.

Do you agree with this?

Thanks,
Mike