OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-jc message

[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

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
implementation canBindBPSSInstance  SchemaVersionList
implementation canFormCPAFrom 2 CPPs or CPA-tempate or CPA-draft plus

For product compatibility, we need to align along

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?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]