RE: CPA composition from multi-role CPPs

[Martin W Sachs <mwsachs@us.ibm.com>]

Dale,

You are right.  The TP team has not discussed data transformations at all
and there is nothing about it in tpaML.  From reading the appended, I am
not sure I understand the motivations behind data transformations.

   If the motivation relates to sending data from party A to party B, the
   two parties have to agree on the schemas that describe the business
   documents as sent and received.  If Party A actually can't process the
   documents in the format as received, then it must provide itself with
   the necessary data transformation tools, transform incoming data the the
   format it needs, and transform outgoing data to the form specified in
   the CPA.  So in this case, data transformation is not a CPP or CPA issue
   at all.

   Another possibility is that a party wishes to provide a data
   transformation service that others can use (buy).  In this case, the
   data transformation service is expressed as a business transaction in
   the colloration protocol document.  Again there is no CPA issue.

If the motivation is different from the above alternatives, please explain
further.

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
*************************************************************************************



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 01/19/2001 01:22:12 PM

To:   "'duane'" <duane@xmlglobal.com>
cc:   "'christopher ferris'" <chris.ferris@east.sun.com>,
      ebxml-tp@lists.ebxml.org
Subject:  RE: CPA composition from multi-role CPPs



Responses in line.


"Moberg, Dale" wrote:

Dale:

Can you please clarify this sentence:

> 2. preference on docexch, when more that one possible, and only one to be
> used for simplicity.

Are you talking about the method for exchanging the document or the
actual business data itself.  If it is the business data itself,  I
think that the correct procedure for CPA terms is that the requesting
company MUST agreee to the data requirements of the Receiving company.


<dalemoberg>
What I was thinking of may be illustrated by the following example:
Suppose ebXML TRP is widely adopted and all XML based PO DTDs/XSDs
arrange to use ebXML messaging specifications. (Well just suppose
it gets used to some extent..!) Still there might be more than
one flavor of PO (c*mm*rc*1 style or *r*b* style), each of which
could ride as an ebXML PO payload, and the differences would not
be reflected at the BP spec level. So when announcing that I could
receive two styles of POs in the seller role, I might need to
announce that I can do either payload type. I think that info
will be reflected in differences in DocExchange elements of the
CPP. The receiving company can do either. And maybe even the
sender could do either in its buyer role! But in a CPA, it might
make it simpler to just choose one style, cXML for example.
That is a situation that illustrates how a CPA can filter
out possible interoperable implementations for other reasons.

As far as who is in the driver seat here (the gorilla), buyers
often are drivers and for the PO BP, I assume they are the
requesting party. So in terms of existing EDI culture, e.g.,
I am not certain that the receiver gets to call the shots.
Maybe I misunderstand...
</dalemoberg>



Please allow me to explain:

A company published their capabilities in their CPP.  One of their
capabilities MAY be to provide XML to XML (or other formats)
transformation.  If they only have a place to publish what businesss
information they need (eg. -

documentRequired="http://www.xcbl.org/docs/xCBL3_0-invoice.dtd"

it must be assumed <IMHO> that any data transformation must be done by
the requesting company before the data is sent.


<dalemoberg>
Believe it or not, we have not yet discussed representing the
data format transformation capabilities within the CPP, as far
as I know. Marty--I don't recall that being in tpaML.

Interesting points...I would naturally be consider this
farther down the road. I don't know what the group scope
consensus would be on this.
</dalemoberg>

THe Requesting company
knows that they can (or can't) transform their own data (eg. an VISA XML
invoice) into the required data specification.  THe receiving company
would have to be queried to ask if they have that caability.  This would
be innefficient but may be a possible last step to be able to complete
an automated transaction sequence.

Sorry for all the ramblings lately - looks like I am sort of joining the
TP Group ;-)

Duane Nickull