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

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: RE: Re-ordering precedence rules

inline <Jacques>

-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Friday, January 24, 2003 12:12 PM
To: jacques Durand
Cc: ebxml-iic-framework@lists.oasis-open.org
Subject: 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.

<Jacques> that seems to cover it all. Bottom line is that XML PutMessage script
should have precedence. For some of these paraemters however,
the ebXML implementation will even have higher precedence, like MesageId.
as it has the "last word" before sending the message.
Only thing I think we don't need to refer to here:
the CPA doc (not CPPA, which is the name of the spec and of the TC...)
probably should not be relied upon (not supposed to be interpreted by
Test Driver - so far in this Framework 1.0). In fact, CPA data will be relied
upon through the implementation where it is installed: we know
this will determine some header attributes (security, reliability, possibly
sender and receiver...) Things that we cannot control anyway by Test Driver in "service" mode.
In your table below:
-  i'd replace "CPA" more generally by "ebXML implementation",
and that would be the highest precedence, possibly for senderparty, receiverparty,
messageId, timestamp.
- I dont think we need "Test Driver autogenerates": all parameters are actually
set by test suite or by ebXML implementation itself, including Timestamp.

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.

<Jacques> for Test Driver in "connection" mode (generating duirectly the message on wire),
I believe precedences are same (except ebXML implementation e.g. MSH is not involved anymore
on driver side)

Cheers,

Jacques
\

Do you agree with this?

Thanks,
Mike