[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC