Input to Jacques

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

1. I like section 1 except that schema flavors omitted. Is that a
Feature?

2. Jacques writes:

"The matrix should address:
(a) compatibility across versions of the same spec. 
(b) compatibility across different specs (different versions, 
and/or different specs:"

Here is an example involving CPPA. We currently have a conformance
statement that basically says that when instances of CPPs or CPAs
conform with a schema, then that constitutes conformance to the spec.
[Well there are a few more constraints, but that is conformance in CPA
so far.

This is not very useful in understanding functionality as implemented.

Here are some items of functionality as implemented in products (partial
incomplete list):

implementation exports    CPP and/or CPA and/or CPA-template
implementation imports    CPP and/or CPA and/or CPA-template
implementation negotiates-at  negotiation-protocol-version(x)
implementation hasEditorFor CPP and/or CPA and/or CPA-template and/or
NDD
implementation canBindBPSSInstance  SchemaVersionList
implementation canFormCPAFrom 2 CPPs or CPA-tempate or CPA-draft plus
NDD


For product compatibility, we need to align along
functionality-as-implemented.

Also, products can in fact support versions that are incompatible (CPA v
1 and v 2 for example).


I am unclear how compatibility between products translates into
compatibility matrix of specifications.

Can you expand a little bit on how these relate?