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