8 messages in org.oasis-open.lists.ebxml-iic-msgRE: [ebxml-iic-msg] MS Conformance ch...| From | Sent On | Attachments |
|---|---|---|
| Jacques Durand | Mar 27, 2002 7:33 pm | |
| Matthew MacKenzie | Mar 27, 2002 11:14 pm | |
| Jacques Durand | Mar 28, 2002 6:55 pm | |
| Matthew MacKenzie | Mar 28, 2002 10:30 pm | |
| Jacques Durand | Mar 29, 2002 5:09 pm | |
| Matthew MacKenzie | Mar 30, 2002 7:40 pm | |
| Jacques Durand | Mar 31, 2002 10:20 pm | |
| Michael Kass | Apr 3, 2002 7:48 am |
| Subject: | RE: [ebxml-iic-msg] MS Conformance checklist: comments | |
|---|---|---|
| From: | Jacques Durand (JDur...@fsw.fujitsu.com) | |
| Date: | Mar 29, 2002 5:09:15 pm | |
| List: | org.oasis-open.lists.ebxml-iic-msg | |
Title: RE: [ebxml-iic-msg] MS Conformance checklist: comments
Matt, Michael:
Looks like the "test requirement" material is almost finalized. You seem also to have detailed ideas on how best execute the test items.
Would it be possible, by end of next week, to send to the group (in preparation to April review):
(a)- a "readable" list of proposed test items for MS conformance (I guess pretty close to what XMLG has sent out) (b)- the subset of these items for "core features" (Level 1), cast into your XML format. (c)- some overall design of the testing procedure(s) and scenarios that would be used to execute these test items?
Thanks for the progress,
Jacques
Matt: just some comments on your comments:
I think a "Conformance service" is probably a better way to request that the MSH create messages and that sort of thing to be tested. It seems impractical to me to have custom code for each vendor in the conformance test suite.
If vendors accept to implement this conformance service, that will indeed be the shortest path to conformance testing (and also to interoperability test later). So it seems like something to explore further. (but we need to publish this design ASAP in Impl. Guidelines, if we push for it, so that implementors are aware of it.) I assume then that vendors who do not want/plan to implement this "conformance service" will still have the option to "drive" their MSH through its API, for test scenarios - their choice?
I'm not suggesting we require vendors to adopt a certain log format, what I am referring to here is more of a tracing format. In the absence of a reference implementation, we need to do this, or employ network sniffing. Maybe I have my head in the mud, please set me straight if I am missing an easier way to capture a complete exchange/transaction.
What I had in mind is: the candidate MSH could send its messages to an URL that would just happen to be our testing end-point listening to this HTTP port (not even an MSH - just a servlet able to dig in the MIME envelope and analyze themessage parts). Again that may not be sufficient - we need to look at all your test cases. So we may all have heads in the mud until that's done :)
Either way, it doesn't really matter. Extracting from an actual CPA is a breeze.
I would favor that, as again there might not be agreement on a common config file format across implementations (some MSH could actually directly use/fetch CPA docs, if I recall). (also, CPA data will actually be more dynamic than config files: new CPAs may show up any time - and expire - during the liefetime of an MSH instance, based on new collaborations)