Re: [ebxml-iic] about 3.5 in spec

From
Michael Kass <>
Date
2003-09-29T06:12:16+00:00
ID
009e01c38651$43d19ef0$
Thread
Re: [ebxml-iic] about 3.5 in spec
Title: about 3.5 in spec

Jacques,

 

  Attached is V0.96 of the spec based upon 
your comments and conference call discussion.

Please see my comments below.

 

Thanks,

Mike

 

  
----- Original Message ----- 

  
From: 
  Jacques 
  Durand 

  
To: 'Michael Kass' ;  
  

  
Sent: Friday, September 26, 2003 1:19 
  PM

  
Subject: RE: [ebxml-iic] about 3.5 in 
  spec

  

  
Mike:

  
 

  
Front page should show right date, and also version

  
(and 
  it is called now a "Committee Draft" V0.95)

  
 

  

  
[MIKE] 
  - Fixed

  
 

  
Comments mostly on the "parameters", which was the main remaining 
  issue:

  
 

  
 

  
---------------------------------

  
3.3.2: Message 
  content parameters - 
  Preceded with a '$' symbol, these parameters represent dynamic message content 
  used to both construct an ebXML message as well as evaluate returned message 
  conformance. These parameters and their description are listed in section 
  3.5.2.

  
 

  
>should 
  be : "...are listed in section 3.5.1"

  
 

  
[MIKE] 
  - Fixed

  
 

  
---------------------------------

  
3.3.2: 
  we need to say a word on the notion of "test step".  We can reuse def 
  from Test Framework 3.3.1, e.g.:

  
"A 
  Test Case is a sequence of Test Steps. A Test Step is an aggregate of one or 
  more operations on the implementation under test. A Test Step usually involves 
  a single message sending or receiving operation, plus some data verification, 
  like checking or enforcing a condition on message header.  A Test Step may also include 
  conditional actions that are a basis for the execution of the assertion within 
  the Test Step itself."

  
 

  
[MIKE] - Included appropriate 
  text

  
 

  
---------------------------------

  
About 
  parameters: we should get rid of $CPAId:

  
testcase_27.4: 
  "eb:CPAId=$CPAId 
  " , why not refer to one of our predefined CPAId ike in other test cases? 
  

  
 

  
[MIKE] - I removed these 
  references

  
 

  
Same for 27.5 and other places. I guess we can do without 
  $CPAId.

  
 

  
[MIKE] 
  - Done

  
---------------------------------

  
 

  
Table 
  of parameters in 3.5.1 below need a few words about *when* these parameters 
  are set, as the expressions where they are used assume they are 
  set,

  
and 
  we should get rid of those that are unused.

  
 

  

  
    
    

      
        
CPAId (suggest to get rid of) 
        

        
 

        
[MIKE] - 
      Done

      
        
Reference to one of 13 MSH configuration 
        instances described in section 
      3.5.3

    

      
        
ConversationId

      
        
As defined in [ebMS]. Represents the 
        ConversationId associated with a particular test case (will remain the 
        same for all test steps of the test case). 
        

        
 

        
[MIKE] - 
        Done

    

      
        
Service (not used here)

      
        
For this abstract test suite:  
        urn:ebxml:iic:test

        
 

        
[MIKE] - 
        Done

    

      
        
Action (not used here)

      
        
As defined in [ebMS]

        
 

        
[MIKE] - 
        Done

    

      
        
SenderParty 
        (instead of using a parameter, e.g. in test case 
        #90, can't we just directly refer to the From/PartyId element in the 
        received message? Same for multi-hop test 
        cases)

        
 

        
[MIKE] - I think that this would be more "convoluted and 
        confusing", plus it "breaks" the simple XPath notation rules for 
        defining messages.  I feel that this attempt to "simplify" would in 
        fact make the XPath expression less understandable,and would argue to 
        keep $SenderParty in the XPath expression as an Abstract parameter that 
        refers to the PartyId of the 
        sender.

      
        
The From/PartyId message 
        value

    

      
        
ReceiverParty 
        (not used 
        here)

        
 

        
[MIKE] - 
        Agreed

      
        
The To/PartyId message 
        value

    

      
        
MessageId (we still have expressions with some of these left: I 
        thought we decided to get rid of 
        them)

        
 

        
[MIKE] - Tests 41, 
        43, 101,  134 (RefToMessageId tests) 182, 183, 184, 187, 
        188 and 193 (StatusResponse tests ) need to "know" the $MessageId of the 
        previously sent message to adequately test conformance, so $MessageId is 
        necessary for those tests I believe.

      
        
As defined in 
        [ebMS]

    

      
        
RefToMessageId

        
[MIKE] - I believe that we can eliminate this 
        parameter, and only use "MessageId' above.  No need to have both, 
        since they refer to the same thing.

        
 

      
        
As defined in [ebMS]. Represents the message ID 
        value of the message that was manipulated in the previous test step, 
        e.g. of the latest message sent or 
        received.

  
 

  
---------------------------------------

  
The 
  parameterized example in Sec 3.5.2 should not show parameters that are not 
  used in the test suite.

  
 

  
[MIKE] - Agreed

  
 

  
 

  
Regards,

  
 

  
Jacques

  
 

  
 

  
    
-----Original Message-----
From: Michael Kass 
    [mailto:]
Sent: Wednesday, September 24, 2003 
    8:56 AM
To: Jacques Durand; 
    
Subject: Re: [ebxml-iic] about 3.5 
    in spec

    
Jacques and all,

    
 

    
 Please see my comments below.   
    Also, I've attached V0.95 based on comments below.

    
 

    
Regards,

    
Mike

    
 

    
      
----- Original Message ----- 
    

IIC_MS_Conformance_TestSuite_V0.96.zip