Re: [ebxml-msg] RE: COnformance Clause

[Doug Bunting <dougb62@yahoo.com>]

Title: RE: [ebxml-msg] Re: Use cases for messageOrdering

To restate some of what I said on this topic during the face-to-face meeting: This seems to be on a collision course with Collaboration Party Profiles.  Rather than having an enterprise say "I support the MSH features described in the CPP", the IIC team would like them to say "My MSH is conformant at this level".  This doesn't appear particularly worthwhile and goes against the mix-and-match nature of the features we've included in the specification.

 

In reality, there's three levels here:

1. A MSH may support 95% of the ebXML-MSH specification.  Side note: The other 5% MUST result in SOAP mustUnderstand Fault or an ebXML error.  The current IIC definition of "weak conformance" doesn't seem to require errors when an unsupported features is requested, just when that feature corresponds to a top-level SOAP extension.  The phrase "behave consistently either as if the feature were absent from the material..." allows a receiving application to silently ignore requests for unsupported features, violating the requirements we've specified. 

2. The enterprise managing the MSH may choose to advertise their support for 75% of the ebXML-MSH specification.  They will configure their MSH to reject requests for the other 25% as described above or no longer be a conformant MSH implementation.

3. Two parties interacting using their MSH implementations will choose to collaborate using 45% of the ebXML-MSH specification.  Again, requests for the non-contract 55% over this channel will consistently result in an error.

While CPP and CPA documents might be used to describe the supported features at some of these levels, they aren't a necessary condition.

Depending upon the configuration of the MSH, features rejected at levels 1 and 2 might (MAY) result in SOAP mustUnderstand Fault errors.  Because level 3 rejections require checking the partner agreements and therefore invocation of the ebXML handler, features rejected at that level should (MUST?) never result in such a Fault.

 

I would propose a conformant MSH implementation MUST include support for all Core Features in the specification and errors MUST result whenever a request is received for a non-supported, non-configured or not-contracted feature.  Any optional feature implemented MUST be supported in accordance with the "strong conformance" requirements.  That's it.

Since we've already required most of these errors, it's unclear a new clause is necessary in the document.

 

thanx,

    doug

 

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

From: Jacques Durand

To: ebxml-msg@lists.oasis-open.org

Cc: Jacques Durand

Sent: Monday, 03 December 2001 14:11

Subject: [ebxml-msg] RE: COnformance Clause

Hi all:

 

In order to prepare for the conformance agenda item (next conference call, next week)

here are the two candidate conformance clauses for MS 1.1 that are most favored by the IIC group (Options  2 and 3),
for your review. (Option 1 was "all or nothing" conformance.)

A conformance clause should normally be included in the final spec document.

 

IIC is actually recommending Option 2  ( 9 members preferred it, while 4 members preferred option 3)

As voters could also express - or not - second choices, we actually used a "weighted" vote that reflects more precisely

the total preference for each option (weight=3 for most preferred, 2 for second if any is mentioned, 1 for third if any mentioned).

Result is: 

33 (thirty three) for Option 2,

30 (thirty) for Option 3,

8 (eight) for Option 1.

 

I think this vote - starting with the design of the clause candidates - indicates how important

some features like Reliability and Ordering have been perceived.

You'll note that a special attention has been given to the interpretation of the keyword "optional" , as

this used to cause some trouble in past MS POC performances (see "definitions"). .

 

Note that  these clauses define conformance levels (rather than profiles),
based on implementation and usage investigation  (see the "rationale" section at the end)
These levels do not attempt to match functionally all possible profiles/agreements (CPP/A),
but should rather be considered as properties of the MSH implementation itself -
establishing a few broad classes of implementations (yet coherent from usage perspective),
so that the number of MSH certification options can be limited.

(A same conformance level roughly guarantees the same CPA playing field for all communicating parties,

supporting several usage profiles,  the detailed definition of which being done/enforced at CPP/A level.)

 

Regards,

 

Jacques Durand
Fujitsu Software
IIC, conformance clause group