[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 summarize: - SOAP envelope and extensions - Security and Error handling modules This does not exactly match what the CC working group is currently planning 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 here.) 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 profiles. 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. Regards, 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