OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic-framework message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

Only comment I would have is that regardless of how we provide the
configurable parameters/defaults, etc. that we understand that any
precedence or resetting of values should maintain the correct timestamps
to understand when to retry after a timeout occurs.  In addition, if
changes must be made in CPA, we should have a new instance (i.e.
ConfigurationGroup).  In the future, when we look more explicitly into
the BPSS and CPPA, we will also have to address maintaining synergy
between these components.  I think all the discussion points to the need
to quickly look at the next phase of CPA integration into our test

-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Friday, January 24, 2003 4:57 PM
To: Jacques Durand
Cc: ebxml-iic-framework@lists.oasis-open.org
Subject: [ebxml-iic-framework] RE: Re-ordering precedence rules


  More comments below

At 02:16 PM 1/24/2003 -0800, you wrote:

inline <Jacques> 

-----Original Message----- 
From: Michael Kass [ mailto:michael.kass@nist.gov
<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 


    I had the order reversed on rule precedence for the Config
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
to construct 
the message. 
If the value is not in the PutMessage declaration, then the
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
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
parameter is present, it is used.  If neither a message declaration nor
Config parameter is set, the the CPPA value is used. 

<Jacques> that seems to cover it all. Bottom line is that XML PutMessage
should have precedence. For some of these paraemters however, 
the ebXML implementation will even have higher precedence, like
as it has the "last word" before sending the message. 

[MIKE] - Understood. "service mode" is a different animal.

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). 

[MIKE] - CPA ( meaning CPAId ) is provided only to pass the ID to the
Test Driver to build the message.
(in connection mode) And in "service mode", won't the "interfaced MSH"
have to know the  semantic meaning of  the CPAId 
and configure itself appropriately? So the Test Driver has to tell the
MSH the id of the cpa, that it will
"implicitly" understand and load.  Since the implementation will likely
send out the majority of "first messages", it would
need to know the CPAId to use, and configure itself appropriately, I
would think.  Comments?

[MIKE] - In connection mode, I know we are NOT expecting a Test Driver
to load a CPA, or CPA-like document. However, much of the info in a CPA
( like endPoint, PartyId, SyncReplyMode, Retries, RetryInterval,
AckRequested ) would really help in writing tests.
Particularly for timing ( calculating timeouts ).   I do not believe
that we could formally "parameterize" all that is needed
to configure a Test Driver ( i.e expand our list of parameters that
we've agreed upon )  
We can, however "informally" do so through the "wildcard"
<ConfigurationItem> element,
with its name/value pair.  So if we "change a CPA" during for a new
<ConfigurationGroup/>, we would also have to change the
"timeout" <ConfigurationItem/> parameter, if the CPA
retries/retry-interval changes. ( i.e. the Test Driver, while basically
may have to store data that it can use for XPath evaluation.. such as
determining if a message arrived too late.
 Does this seem reasonable?

[MIKE] - It seems logical that we could do this, since we are following
the "spirit/semantics" of a CPA, using our own defined parameters to get
job done.  However, our Test Suite would not be portable, unless someone
else implemented a Test Driver that
understands our "timeout" <ConfigurationItem> parameter... i.e.. it
hasn't been "formalized" as a parameter


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,
sender and receiver...) Things that we cannot control anyway by Test
Driver in "service" mode. 

[MIKE] - Assuming we are in "service mode" yes.  However, even in
"service mode", the Test Driver
could no doubt benefit from the data in the CPA.  However I understand
that at this point
CPA is at best an abstraction to the Test Driver.

In your table below: 
-  i'd replace "CPA" more generally by "ebXML implementation", 
and that would be the highest precedence, possibly for senderparty,
messageId, timestamp. 
- I dont think we need "Test Driver autogenerates": all parameters are
set by test suite or by ebXML implementation itself, including

[MIKE] - I disagree that we will be coding Timestamps by hand in
"connection mode". I agree that in
"service mode", the implementation does the auto-generation. 
But in "connection mode",  I'd much rather have a Test Driver pound out
the clock times.  
The Test Suite is just an XML file. The Test Driver will generate
Timestamps and MessageIds by default, 
unless we "override" them with a Configuration parameter, or explicitly
declare them in the Test Suite document.

Maybe I'm not interpreting what you said correctly?

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
Declaration     Config Param            CPPA 
$CPA (Id)
XML PutMessage Declaration      Config Param 
$ConversationId                                                 XML
PutMessage Declaration      Config Param            Test Driver 

$Action                                                         XML
PutMessage Declaration      Config Param            

XML PutMessage Declaration      Config Param            Test Driver 

XML PutMessage Declaration      Config Param            Test Driver 


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

[MIKE] - Understood

<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) 



Do you agree with this? 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC