ebxml-tp message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: CPA composition from multi-role CPPs

Responses in line.

"Moberg, Dale" wrote:


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. 

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

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


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

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. 

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC