Re: [ebxml-jc] FW: Input to Jacques

["Karl F. Best" <karl.best@oasis-open.org>]

I've put him back on the list.
-Karl


Dale Moberg wrote:
> 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.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>
>  
> 
> 
> 
> 
> 


-- 
=================================================================
Karl F. Best
Vice President, OASIS
office  +1 978.667.5115 x206     mobile +1 978.761.1648
karl.best@oasis-open.org      http://www.oasis-open.org