RE: [ebxml-msg] RE: COnformance Clause

[Martin W Sachs <mwsachs@us.ibm.com>]

Jacques,

You said: "Note that NOT everyone  agrees what should be in "core"..."

If not everyone agrees on what should be in "core", that is a big problem
that needs to be dealt with.  Some of this lack of agreement may be due to
ongoing discussions on what should be in MSG V 1.1.  Once V 1.1 is out, it
should make it perfectly clear what should be in the core or the team has
failed to do its job.  The core is all features which are not explicitly
stated as optional.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Jacques Durand <JDurand@fs.fujitsu.com> on 12/05/2001 10:25:08 AM

To:    "'Doug Bunting'" <dougb62@yahoo.com>, ebxml-msg@lists.oasis-open.org
cc:
Subject:    RE: [ebxml-msg] RE: COnformance Clause




Doug:

see  comments in line.
-----Original Message-----
From: Doug Bunting  [mailto:dougb62@yahoo.com]
Sent: Tuesday, December 04, 2001 12:47  PM
To: ebxml-msg@lists.oasis-open.org
Subject: 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

----- 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