RE: [ebxml-iic-msg] MS Conformance checklist: comments

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

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)