FW: Versioning compatibility matrix [reposted]

1. Version annotation:
----------------------

Version annotation is a standard way to annotate a doc, a schema, an 
implementation, a run-time artifact (e.g. message) with proper version ID.
We'll have to decide where to recommend version annotations. It can be a 
small XML document, just listed in a doc (e.g. Appendix) or inserted in 
a schema:

<specificationId>
<fullname>ebXML Messaging Service</fullname>
<refname>ebMS</refname>
<version>2.0</version>
<revision></revision>
[<feature> optionally, a subset of the spec is identified here <feature>]
<date>(xs:date)</date>
</specificationId>

NOTES: 
- the "refname" is a contraction that is expected to be used in 
other docs when they refer to this spec. E.g., in the reference section of
other docs, for the above example, "[ebMS-2.0]" should be used, in a 
standard way (reference = <refname> ["-" <version> ["-" <revision> ]])
- run-time support should be recommended (e.g. an implementation 
should be able to "return" such information when queried, e.g. via a Ping.)


2. Compatibility matrix:
------------------------

The matrix should address:

(a) compatibility across versions of the same spec. 
(b) compatibility across different specs (different versions, 
and/or different specs:

(a) compatibility across implemented versions of the same spec: 
It should allow to answer questions like:
- is implementation of spec X.0 compatible with newer X.1? (always? 
sometimes? never?)
- is implementation of latest spec X.1 compatible with X.0? 
(always? sometimes? never?)

NOTES: 
- We may have to go to more detail here, because, for example, CPPA 
or CPPA negotiation will expect certain functionality from BPSS, so it 
may be as specific as an element or function.
(see the <feature> element in <specificationId> above).

(b) compatibility across implementations of different specs (and across 
different versions.)
Here, it is important to first "qualify" the type of relationship 
between specs. 
We should consider the different natures of dependency between two specs:
(i)- integration dependency (an implementation of spec A uses an implementation of spec B)
(ii)- interoperability dependency (an implementation of spec A is expected to interoperate
with an implementation of spec B).

Further, in case of (i), the integration can be:
- mandatory (spec A uses spec B as a necessary component)
- optional (spec A uses spec B as an optional extension, e.g. binding.)

For each of these types of dependencies, incompatibility between A and B 
will not have same meaning, implementation-wise.

NOTES: 
- Interoperability and integration dependencies do not yield a yes / no 
compatibility answer: there may be varying degrees of interoperability on core 
functions. Which brings up a possible attribute of the compatibility
assessment: the conformance level or profile, the usage profile of a spec.

The compatibility matrix will be "distributed" in the sense that each
specification document will list all its known dependencies, and qualify them.
The reunion of all these dependencies will represent the "matrix".
These relationships are likely to be oriented (a spec A "uses" a spec B, either for 
integration or interoperation).
The known dependencies of spec A with other specs could be described as:

<specificationDependencies>
    <specificationId> <!-- this spec ID -->
    </specificationId>
    <relatedSpecification dependency="integration" type="binding" level="required">
        <specificationId> <!-- related spec ID -->
        </specificationId>
    </relatedSpecification>
    <relatedSpecification dependency="interoperability" type="messaging" level="partial">
	  <profile> (the conformance profile or usage profile under which the dependency is considered)</profile>
        <specificationId> <!-- related spec ID -->
        </specificationId>
    </relatedSpecification>
    ...
</specificationDependencies>


The matrix would be the union of all these <specificationDependencies> 
elements, for all specs.