RE: [ebxml-msg] RE: COnformance Clause

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.

[Jacques Durand]

Seems to me there is confusion going on between conformance and CPP. First of all, an MSH implementation does not require the existence of a CPP/CPA, at least in 1.1. Even so, it would not make much sense for a user/enterprise to say "I support the MSH features described in the CPP". Which CPP? An enterprise will use an MSH to support many business processes, requiring different CPP/CPA values. Conformance levels are a way to define broad categories of MSH implementations - but not too many, so that functional mismatches between communicating MSH is reduced upfront and at least well understood. A marketplace can tell its trading parties: "you'll need a level 1 MSH." That in fact defines a class of communication and QoS agreements (e.g. as in CPA) that the market place expects you to meet.

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.

[Jacques Durand] I concede the current wording of "weak conformance" leaves a lot to the implementors on the way to handle unsupported features, as it requires errors (always for mustUnderstand SOAP faults) only if this causes "undesirable behavior" otherwise. We can fix this. But frankly, I would rather see the level of warning as configurable. The reason is, generating an error message each time you do not support a feature in another message may create unacceptable overhead - and annoyance - in some deployments. (Could we relax the "error notification" required in 1.2.4? or make it OK to log the error locally?)

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.

[Jacques Durand] The notion of conformance level is precisely there to not have to define what "75%" or 45% means. I frankly would not know what to do of a vendor who sells "75% conformant" MSHs. I would not know upfront if I that would be good enough to do business with my partners, one having a 70%, the other a 80%, etc... But if my trading partners have all decided to use Level 1 conforming MSH, then I know what to shop for, and I know there will be no surprise. (Furthermore, I know I am OK with a Level 2 MSH...) We see conformance levels really as a product attribute.

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.

[Jacques Durand]

See my comments before. I agree that the "core features" should match the lowest level of conformance. Note that NOT everyone agrees what should be in "core"...

I believe the current "core/additional" partition is the only thing that may collide with a conformance clause (as it is one in itself). Not the CPP/CPA.

Thanks for commenting,

Jacques

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

thanx,

doug

ebxml-msg message