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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-dev] Re: [EDI-L] Announce - Latest Article on ebXML


I won't split hairs over the meaning of "integral" so I concede your point.  I would like
to clarify, however, that in my discussions I have considered the CPA/CPP and BPSS
specifications separately.  As you are aware, the modular nature of the ebXML
architecture allows one to use CPA/CPP without a BPSS, and vice versa, allows use of MHS
without CPA/CPP, allows (future) use of other message handling such as XMLP with CPA/CPP
instead of ebXML MHS, etc.  So, it only makes sense for me to consider them separately.
If I were to consider BPSS and CPA/CPP together, my estimate would be even lower for
CPA/CPP due to my lower assessment for the BPSS.

BTW FWIW - I think the original tpaML by itself was a much more workable concept in the
near term than the combined ebXML CPA/CPP and BPSS.  Less capable to be sure, but
simplicity has its virtues...


Martin W Sachs wrote:

> Mike,
> Regarding: "is covered by the BPSS, which is only pointed to by the CPA/CPP
> and is
> not an integral part of the CPA or the CPP." The CPP and CPA contain what
> amounts to a normative reference to a BPSS instance document. That makes
> the BPSS instance document just as integral a part of the CPP/CPA as the
> element in the CPP/CPA that points to it.  The BPSS instance document has
> the job of defining the choreography of the message exchanges.  Without it,
> we would have had to invent one to embed in the CPA (or to use the
> choreography that came with tpaML).
> Regards,
> Marty

Michael C. Rawlins, Rawlins EC Consulting

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC