OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ebxml-iic] Conformance Clause update & issues

Hi all:

This is  an update on the Conformance Clause status.
Your input  / opinion is actually requested...

As you may know, the  Messaging Services spec is currently  revised,
which makes it a moving target for conformance clause work - but also
an opportunity. A preliminary draft (V1.05) is circulating.

On the positive side, V1.05 is addressing conformance concerns much more

explicitly than V1.0. A set of core features is being proposed. To
- SOAP envelope and extensions
- Security and Error handling modules

This does not exactly match what the CC working group is currently
as "base conformance level", but is close.
(We are mostly targeting a baseline conformance level that supports
basic interoperability,
and that could easily be remotely tested. So features such as "security"
may not be required

Another good thing in V1.05 is the grouping of features in modules,
which are logical
(and implementation) entities that will make it easier to define
conformance levels or

A not so good thing is that compatibility with 1.0 seems broken.
New QoS elements such as "duplicateElimination" are being added.  That
is rather brutal
for a minor revision that early after the initial release. (
compatibility breaks would not
be a problem for major releases, and it would be better to "space" them
as much as possible).

But another aspect of V1.05 that IIC-CC is more concerned with, is the
inclusion of
a conformance clause.
Here please review the attached comment / feedback that I propose
to communicate to the MS TC. Your comments are welcome.


Jacques Durand
chair of the Conformance Clause working group

The latest evolution of the MS specification  (1.05) is explicitly partitioning 
the MS features into core (mandatory)features  vs. optional features. 
We see the following problems with this:

1. This preemptively specifies the conformance clause as built-in in the body 
of the specification. It will then be difficult/confusing to specify several 
levels or profiles of conformance, as each feature module in the spec is 
qualified up-front as either "core" or "optional". The reality is, the same module 
may be optional for a level of conformance and mandatory for another. 

2. This up-front qualification of modules of features will then likely collide with
the Conformance Clause. The OASIS Conformance Requirement Guidelines recommends
this clause to be a separate section, added to the specification.
The conformance clause addresses practical criteria and concerns that the core
specification may want to remain somehow independent from, and that may 
actually evolve independently from the main body of the specification: 
usage profiles, ease of test, interoperability agenda, etc.  

3. The way the spec is currently written, implicitly defines a 
"core" conformance level, by making everything else optional. Because the remaining 
optional features are not tied to any conformance level, it is then sufficient 
for a vendor to implement just the core features, and yet claim to be 
technically "fully compliant" with the entire spec,
(without having to refer to any conformance level) 
Such a claim will be technically right, as everything else is optional...

4. At a more detailed level in V105, we see the following problems with an 
arbitrary partitioning core/optional:
- Some Core modules (non-optional), like Security module, is actually de-facto 
optional as it may be void of its elements (0 or more ds:signature) and may 
actually be completely absent from the header. 
- the "optional" quality of a module can actually be conditional: 
the Message Status Service is listed under Optional features, but it is actually 
NOT optional when the Reliable Messaging module is used.


As a consequence, we suggest that the MS specification does not directly 
qualify its modules of features as core vs. optional. 
(however, formal/logical dependency rules between modules, e.g. M2 is required 
if M1 is implemented, still belongs to the main spec)
Only an exhaustive implementation will be "fully conformant". 

A conformance clause should be added that defines levels/profiles of conformance, 
and for each of these, which modules are required and which ones are optional. 
(in other words, we believe there are two usage of OPTIONAL keyword: one normative, 
the other one about conformance, and that they should not be confused.)
More detailed conformance requirements can be specified in addition in the clause.
The IIC working group offers to cooperate with MS TC in this effort.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC