[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,
Your suggestion would work. My only concern is that the subset schemas
would not be conformant with the CPPA specification if they omitted
elements or attributes that have minOccurs greater than zero.
My suggestion for the subset profiles was to define "prototype" CPAs that
omit what is not needed and has minOccurs="0", and have values already
filled in that are not to be changed. The schema would remain the approved
CPPA schema. Using separate namespaces is a good idea.
These subset CPAs would be CPA templates that also would conform to the
future automated negotiation specification. As with any CPA template, the
subset CPA templates could be described by the automated-negotiation
Negotiation Descriptor Document to show what elements and attributes are
modifiable. So, doing it the way I described would also be conformant with
the automated negotiation specification when it is approved. This would
also facilitate using a CPA composition tool to compose the subset CPAs.
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: Martin W Sachs/Watson/IBM@IBMUS
com> cc: Dale Moberg <dmoberg@cyclonecommerce.com>, "Cppalist (E-mail)"
<ebxml-cppa@lists.oasis-open.org>, ebxml-iic@lists.oasis-open.org
08/25/2002 10:23 Subject: Re: [ebxml-cppa] Re: [ebxml-iic] Simple trading partner
PM configuration for 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