Re: versioning and compatibility matrix

["Monica J. Martin" <Monica.Martin@Sun.COM>]

> Durand: All:
> here is a first cut on a old, dormant (but not forgotten) assignment on
> versioning and compatibility matrix across specs, matter of reviving 
> this thread.
> The doc attached mostly focuses on requirements, with hints of solutions.
> Probably too late for tomorrow discussion, but something to chew on
> over holiday time...
>
mm1: Comments inline.
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>
</specificationId>

mm1: May be important to have an official date attached to the version.

NOTE: 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> ]])

Note that 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) implementation compatibility across versions of the same spec: 
should allow to answer questions like:
- will implementation of spec X.0 be compatible with newer X.1? (always? 
sometimes? never?)
- will implementation of latest spec X.1 be compatible with X.0? 
(always? sometimes? never?)

mm1: You 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 or more generic as per 
version (spec-to-spec).

A more general matrix would also address different specs (not just 
different by their version):
(b) implementation compatibility across specs (different versions, 
and/or different specs:
Here, it is important to first "qualify" the type of relationship 
between specs:
If spec A is "using" spec B: does using mean:
- spec A uses spec B as a necessary subset.

mm1: Mandatory because of direct dependency.

- spec A uses spec B as an optional extension, e.g. binding.

mm1: Represents an optional function within or across two or more 
specificiations.

- an implementation of spec A is expected to interoperate with an 
implementation of spec B.
For each of these types of relationship, incompatibility between A and B 
will not have same
meaning, implementation-wise.

mm1: Interoperate as is or with transformations, or other changes to 
provide support? We may have varying degrees of interoperability on core 
functions. Which brings up at what level or profile is the 
interoperability or compatibility held?

Then, a "using" spec (role A above) can list all the "used" specs (role 
B) with which it is compatible (always, partially, never), for each of 
the usages above.
If these relationships are oriented (here from A to B), then we could 
require each spec to list all known dependencies with other specs. 
Something like:

<specificationDependencies>
    <specificationId> <!-- this spec ID -->
    </specificationId>
    <relatedSpecification usage="binding" compatibility="full">
        <specificationId> <!-- related spec ID -->
        </specificationId>
    </relatedSpecification>
    <relatedSpecification usage="interop" compatibility="partial">
        <specificationId> <!-- related spec ID -->
        </specificationId>
    </relatedSpecification>
    ...
</specificationDependencies>


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

--------------- initial requirements (old email from Colleen)
(1)  We feel there is a need for an OASIS-wide way to implement shema 
versioning and documentation across OASIS approved schemas. More 
generally, specifications should include a formal representation of 
their version number, e.g. using a common XML document format. All this 
would make it easier to obtain, query, and process the version number of 
an implementation.

mm1: This has been requested by ebBP users.

(2) We also feel there is a need for a common way to represent 
compatibility links to other specs.  While the ebXML Joint Technical
Liaison Team  is developing an ebXML standards compatibility matrix, a 
more formal way to code a compatibility matrix (for integration as well as
interoperability) is required across OASIS, ideally a model that could 
be processed by a tool and well understood across specifications.
------------------------------------------------------------------------