[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Re: [ebxml-iic] Simple trading partner configurationfor ebMS
Marty, Your comments are right on the money. I don't really want to start flooding the world with more standards, but I really want to see a simple and short TPA in the spirit of the schema I just sent out. The "profile" concept is interesting. I would like to see a set of profiles in the form of a few schemas which use the core CPPA schema as a type library. Each schema would have a slightly different namespace, so that a CPPA implementation would be able to understand which profile is in use. Does that jive with what you were thinking? Cheers, Matt On Sunday, August 25, 2002, at 12:43 PM, Martin W Sachs wrote: > > > > > > Matt, > > Thanks for the proposal. I'm sure that the team will give it serious > attention. > > I have a concerrn that publishing a normative subset schema may confuse > more than it will help. It is not clear that only one subset schema > would > be sufficient. I have the following thoughts. > > What may be the right subset schema for your customer set is not > necessarily the right one for other customer sets. Another approach, > which > has worked well in other feature-rich standards, is to define one or > more > "CPPA Profiles" that apply to different customer sets, industry > verticals, > etc. Such a profile defines those features that enterprises in a given > "sub-industry" must support. It can specify values for those elements > and > attributes are the same in every CPP or CPA in the group and list those > features whose cardinality includes minOccurs="0" that are not to be > used. > Each profile would include CPP and CPA Templates (a prototype of the > subset > CPP or CPA) that expose the required features and leave out everything > not > needed whose cardinality includes minOccurs="0". These profiles could > be > developed by the appropriate industry groupings, coordinating with the > CPPA > team. The could be published either by the individual groupings or by > OASIS > as technical reports. With this approach, there is no need to have > subset > schemas since the subset CPPs and CPAs would validate against the > standard > CPPA schema. Also, by not omitting CPPA elements and attributes whose > cardinality is greater than zero, standard CPA deployment tools and > run- > time middleware would be able to handle the subset CPAs. > > A CPP-CPA composition tool could be designed to be tailored for > profiles > and to show the CPP or CPA author minimal complexity. Its GUI would > present to the author only those elements and attributes that require > decisions for the selected profile. Elements and attributes of > cardinality > minOccurs="0" that the profile defines as absent would not be shown to > the > author. Also, elements and attributes whose values are fixed by the > profile would not be shown to the author. The tool could also include a > feature to be used for defining new profiles. Profile support should > be a > good value-added opportunity for CPPA tool vendors. > > Regards, > Marty > > > > *********************************************************************** > ************** > > Martin W. Sachs > IBM T. J. Watson Research Center > P. O. B. 704 > Yorktown Hts, NY 10598 > 914-784-7287; IBM tie line 863-7287 > Notes address: Martin W Sachs/Watson/IBM > Internet address: mwsachs @ us.ibm.com > *********************************************************************** > ************** > > > > Matthew MacKenzie > <matt@xmlglobal. To: Dale Moberg > <dmoberg@cyclonecommerce.com> > com> cc: > ebxml-iic@lists.oasis-open.org, "Cppalist (E-mail)" <ebxml- > > cppa@lists.oasis-open.org> > 08/24/2002 12:16 Subject: [ebxml-cppa] > Re: [ebxml-iic] Simple trading partner configuration > PM for ebMS > > > > > > > > Dale, > > Here you go, The schema and a sample is attached. I have to say that > this schema came to be out of a perception that CPA is a bit too > complex for the average user. My company has fully implemented CPA v2, > so the design of CPA isn't really at issue. I've recently had to > maintain 24+ CPAs, and I can tell you that it is a serious pain. > > Maybe this group could consider a Simple CPA schema, which is a subset > of the full schema. I believe the docbook guys did this as well to try > and make it easier to get users feet wet. 70/30 or even 60/40 is > probably the kind of markup reduction I'm thinking of. Maybe schema > modularization is the name of the game. You can decide. > > Regards, > > Matt > > > > > > > > On Friday, August 23, 2002, at 06:38 PM, Dale Moberg wrote: > >> Hi Matt, >> >> I skimmed the schema you provided. I guess it >> is one of the "70/30" optimization gambits. >> Anders from OpenEbXML has proposed a similar >> lightweight schema within the JSR 157 group. >> >> As such, I think it might be worthwhile sending >> to the ebxml CPPA TC for consideration. It >> is especially interesting in that it might promote >> adoption of profile/protocol-binding technologies, >> because of its minimalisticYetEssential view of >> configuring the b2b side of the MSH. >> >> So the advantage I see is that it is geared for the >> ebXML MSH (it may ignore some of the PKI support >> the security risk document recommended--I would >> think about adding that in, at least optionally). >> >> A political problem is that it more or less dispenses with the BPSS >> hooks (and so becomes choreography/flow/orchestration/process >> independent). That may be feasible via the modularity doctrine, >> however. >> >> Would you be willing to cross post the example and schema >> to ebXML-CPPA? Maybe a few words in support of a CPA-lite >> could accompany the post? >> >> Thanks, >> Dale Moberg >> >> >> >> -----Original Message----- >> From: Matthew MacKenzie [mailto:matt@xmlglobal.com] >> Sent: Friday, August 23, 2002 4:07 PM >> To: ebxml-iic@lists.oasis-open.org >> Subject: [ebxml-iic] Simple trading partner configuration for ebMS >> >> >> Team, >> >> As we discussed during the F2F today, I've put together a simple CPA >> replacement that has the bare minimum configuration information for 2 >> parties. These could be what we use for specifying MSH configuration >> for conformance and interoperability. It also could form a CPA >> replacement, which is designed over time to meet vendor needs as per >> discussions we had today (Myself, Hatem@IPNet, Jeff@Cyclone). >> >> If you're interested in this development for use beyond testing, >> please >> help me out by supplying feedback -- is there anything missing that a >> good MSH needs out of a TPA? >> >> Regards, >> >> Matt > > > #### tpa.xsd has been removed from this note on August 25 2002 by > Martin W > Sachs > #### tpaSample.xml has been removed from this note on August 25 2002 by > Martin W Sachs > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC