[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Input to Jacques
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?