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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

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


Subject: Re: [ebxml-iic-interop] comments on latest BIP


Title: comments on latest BIP
Jacques,
 
   Please see my comments below labeled [MIKE]
 
   I am attaching the merged result file of your edits, along with
my fixes based upon your suggestions. My fixes  are:
 
1) addition of the 3 new rows to the BIP tables (ErrorURL, NotificationURL, TimeToLive)
2) added additional column to BIP parameter instance table for "mshc_5" configuration
2) added appropriate Action names to Test Requirements Preconditions
 
  For some reason, the TOC is corrupted, and ( includes text from the document in the TOC)
It may have to do with the Test Requirements Table.
 
  In any event, in order for people to get a review of the specification, I am submitting the merged 
document for review by the TC.
 
Mike
 
----- Original Message -----
Sent: Thursday, April 03, 2003 11:37 PM
Subject: [ebxml-iic-interop] comments on latest BIP

Mike:

Main updates I propose and/or comments: (se doc attached)


- Your delete of the "conformance clause " is fine (section 1.4), as discussed at last meeting.

 

[MIKE]  - OK , I removed this and merged it

 

- BIP parameter table misses 3 entries I believe. (see in attached updated copy)

[MIKE] _ Added these 3 entries and merged it ...although I am still unsure of the meaning of the TimeToLive parameter, since it is a finite time ( often called "TimeToDie", since that is what it truly represents.  My question is, what value, either as a "profile" parameter representing the context of a test case or as a real hard-coded parameter in a test suite.. could this have?   Especially since it is the result of computation of RetryInterval plus Retries.. both of which are ALREADY BIP parameters?  I think that a "TimeToDie" parameter would have more meaning ( as a "delta" time interval indicating how long a message should be "alive" after being sent ).  This would be useful for conformance testing ( especially with its CPA agnostic Test Driver ).. but again would not have much relevance for interop testing. Comments?

- Test case 1.5 cannot have same parameter set (CPA) as case 1.6 (mshc_4):
1.5 is async and signed, and 1.6 is synchronous and not signed.
It seems that we still need the additional table column mshc_5 for 1.6:
mshc_5 = same as mshc_3, but with  syncReplyMode = "signalsAndResponse" instead.

 

[MIKE] - Agreed.. added "mshc_5 column in table and merged it based upon above info. Will also update external executable test suite to reflect reference to "mshc_5 CPAId in test #1.6

 

- updated some figures that needed to: Fig 11 (you forgot to report my update)
and Fig 7 (should not say "signed M1").

 

[MIKE] - OK - merged

 

- in 3.2, I reduced and reworded the section you have deleted,
because I think we should still distinguish and describe these "profile options"
before and independently from the parameters of the the test suite they map to:
In other words, there are two different things:
(a)- the MS-BIP, which is a profile of interoperability (with its options).
(b)- the "MS-BIP test suite", which verifies the MS-BIP (with its parameters)
We want to require people to specify the options of the MS-BIP they are claiming to interoperate with,
(and these options will be quoted in future certificates or badges)
at a more abstract level than the test suite and its corresponding parameters.
So I have separated both in two different sections: 3.2 and 3.3...

 

[MIKE]  - OK - merged

 

- I do have  a problem with the req table in 4.2,
because the reqs are too inquisitive as worded: as the test cases are verified
at application level, we cannot make any requirement on the header content, etc,
like we do in conformance. We can only make "app level" reqs.
 I have tried to reword the 5 first test cases.
If fixing this table takes too much effort, we don't need to include it...

[MKE] - I like the modifications... they are more concrete.  One reason for including this
table in the specification is that it is actual "Test Material" required by the ebXML Test Framework to run
the executable Test Suite. Also, Test Suite Specificatsions generally include Test Requirements as part of their
specification.. so this is good to have.
The only modification that I made to them was adding all of the "Action" names in the preconditions.. which I think
clarify the requirement.

 
 
 
 

Cheers,

Jacques

<<BIP0.92.zip>>

IIC_MS_Basic_Interop_TestSuite_V0.92_merge.doc



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