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: .
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:]
Sent: Wednesday, February 11, 2004 10:00 AM
To:
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>
