FW: Input to Jacques

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

Title: Message

J acques said this did not show up on the list.

Jamie, Jacques had a mail hiccup that unsubscribed him. An Oasis administrator needs to put him back on.  

 Dale

===

 

All:

1. Here is my "plan B hotel" info for N.O.
2. inline answer to Dale.

-----------------------------------------
Baronne Plaza Hotel (very close to Marriott, ~1 block N.W of French Quarter)
 <http://www.neworleansonline.com/cgi-bin/click.count.pl?url=http://www.baronneplaza.com>
210 Baronne Street, New Orleans, LA, 70112
Phone: 504-522-0083, Toll-free: 888-756-0083
Fax: 504-522-0053
Located in the heart of Downtown New Orleans, the Baronne Plaza Hotel offers comfort, elegance and convenience. Steps from the French Quarter and Harrah's Casino. For our guest convenience we offer 181 standard and deluxe rooms with all the amenities, an on site restaurant and bar, meeting room and business center as well as an exercise room and spa. Email: barplaza@bellsouth.net.

Central Business District/Warehouse District
Check availability to reserve your room now. <http://www.neworleansonline.com/cgi-bin/click.count.pl?url=http://www.turbotrip.com/mpr/rfd/owa/rfqa2.redirect?p_agent=2182&p_hotel=1177>

http://www.baronneplaza.com/

Example:
Reservation: from
Sunday night: $99
Monday night: $79
Tuesday night: $79
Wednesday night: $79
Thursday night: $133

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Wednesday, February 11, 2004 10:00 AM
To: ebxml-jc@lists.oasis-open.org
Cc: Jacques Durand
Subject: Input to Jacques

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

<JD> Yes, we may need to introduce a taxonomy.</JD>

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

<JD> Right. Same for an MSH supporting two ebMS versions.
I see then a compatibility matrix making most sense at specification level,
not implementation level.
(stating cross-specification dependencies, standard-level backward compatibility, etc.)
On the other side, implementations or products will have a "signature" stating which
of various standards/features they support in various ways. Interoperability
is just one of the "support modes" (like export / import / negotiates-at  ...).
Now, I see the "spec compatibility matrix" as complementing such a signature,
and providing some inference capability: e.g. if the product signature
says "product XYZ imports artifacts of spec A 1.1",
and if A 1.1 is 1.0-compatible (say the matrix), then you could infer:
"product XYZ imports artifacts of spec A 1.0" (or it should!)</JD>

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

Can you expand a little bit on how these relate?

<JD> As suggested above, a matrix would make sense at spec level only.
I feel that when it comes to implementation, we may have to distinguish:
- artifacts (a "consumable" conforming to a spec, e.g. if the spec is about a document format, message, record structure)

- processors (which process artifacts, but also the behavior of which may be subject
to specification.)
So obviously CPPA spec is about artifacts. ebMS is 90% artifact (message), 10% processor
(behavior).
So a compatibility matrix about specs, will probably help understand artifacts better,
e.g. tell that artifact compliant with A 1.0 will be processable by any processor
supporting artifacts A 1.1.
But the capability of a "processor" is not limited to  only compatible features
as you noted.
I think one of the challenges here is to nail the right "implementation model"
that applies everywhere, so that we can express rules on artifacts, product signatures,
in the same annotation language. </JD>