[ebxml-jc] 2/10/2004: Updated Comments on Compatiblity Matrix

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

See below, thanks. Includes previous and some updated comments.

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. Also, per the discussion today 11 Feb, consider a convention 
for contraction.

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? Particularly with your examples 
above and the references on 'using' below, we may need to address what 
interoperability really means. Is it against a profile of mandatory core 
functions?  Need to also designate if part of one specification is used 
in another, if that involves mandatory or optional elements, and whether 
they are mandatory or optional in the target specification (using 
specification).

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.
------------------------------------------------------------------------