ebXML IIC TC -- conformance clause subcommittee

[Philippe De Smedt <pdesmedt@agentisinternational.com>]

All,

Please find attached a document by Jacques Durand of Savvion, outlining the
role of the Conformance Clause subcommittee that we established under the
ebXML IIC TC.

Those of you that are interested in working on this committee, please let
the list know. In a nutshell, the Conformance Clause subcommittee will focus
on ensuring that each of the ebXML specifications clearly state what
conformance means in very specific terms.

Thanks.

-Philippe

----- COnformance Clause sub-group kick-off (Jacques Durand) ----------

1. Proposed way of operating the Conformance Clause Working Group (CCWG):

(a) In order to not clutter the IIC mailing list, I propose all persons interested
in (actively) participating to the "COnformance Clause" send me their email. 
We'll define a sub-list (maybe a subgroup mail: ebxml-iic-cc). 
I guess all TC liaisons are automatically in it...(because of TC input.) 
We'll publish to IIC mail list only significant outputs.

(b) This mailing sublist can be used as a forum, where I see a first phase of 
opinion / position sharing. I give below a few lines that may help
focus the interventions.

(c) Mode of cooperation with other TCs: 
Clearly, each TC is expected to provide input about the COnformance Clause of their spec.
In fact, the CC is supposed to be itself part of the specs, according to the OASIS
guideline: "... Ensure that conformance is consistently addressed within a specification or
across related specifications." We need to define how this cooperation works.
I propose that the IIC CC group has the first cut at it - i.e. comes up with 
some preliminary proposal or options for the CC. 
Then our TC liaison passes it to the spec TC, and we ask their feedback.
After a few rounds, we should come to an agreement. 
I prefer this rather than waiting for the expert TCs to initiate, 
because (1)by giving the TCs  something to chew on first, we will not waste time, 
(2) the CC format depends on some questions (see 5) that we should try answer ourselves.

(d) Input from user-related groups.
We also will get the users perspective from groups such as DGI,
as to what are the meaningful levels or profiles of conformance / interoperability for users.

2. Reference info:

Everyone intrested should read the OASIS "Conformance Requirements Guideline" as well as
other doc (www.oasis-open.org, see "conformance" under Technical Work list).
An extract:
"...The conformance clause defines the requirements criteria: "what" must
conform, and "how" conformance can be met. A conformance clause can:
a- Ensure a common understanding of conformance and what is required to claim
conformance to a specification
b- Ensure that conformance is consistently addressed within a specification or
across related specifications.
c- Promote interoperability and open interchange
d- Encourage the use of applicable conformance test suites as well as promote
uniformity in the development of conformance test suites.
..."

3. Scope of activity:

We will start with Messaging Services. However, people not concerned with
MS and involved with other TCs, may already start similar work in other TCs.
They should feel free to work on other spec areas, and contact - through 
IIC liaisons - these TCs to gather their input.

4. Timing:

Deliverable: a conformance plan is expected "approximately 3 months" after
first IIC meeting. I assume that the Conformance Clause should be defined much earlier,
as the plan includes also Tests, and 3rd party labs and conf guidelines.
I would very much like to see a formal MS conf clause proposal by the second half of october.

5. On the TODO list:
 
Preliminary Questions to answer:

5.a - Should the CCWG  define (1) levels of conformance, or (2) profiles of conformance,
for the MS specification?
- Profiles reflect a particular community of users. For instance, some
industry group such as banking (emphasis on security, reliability). 
Or reflect a particular context of operation, e.g. networked MSH
(emphasis on routing features, traceability, manageability of MSHs).
- Levels reflect a hierarchy of feature groups, from the core features in
bottom level, to richer sets that extend on previous levels. Conformance
with level N guarantees conformance with levels < N.

5.b - The WG will have to take position regarding the level of 
interoperability that is assumed by conformance. Should minimal conformance 
guarantee interoperability? If yes, then this means strong requirements about
 the transport layer (should be HTTP?). If no, then we'll need to define
separately "interoperability" profiles.

5.c - How easily should conformance be tested?
I believe we should keep this in mind at all time, even when defining the conf. clause. 
Could basic MS conformance  be checked only based on an interaction test with a
"reference MSH", with minimal - if no - setup requirements on the  application layer 
of the target MSH? That would be ideal.

5.d - How do you see the role of our TC liaisons?
This is more an organizational issue. This is another way to address TC cooperation.
Should we expect our TC liaison to act as a domain expert when drafting the CC, and drive it
somehow, or is s/he just a contact / informer?