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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-stc message

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


Subject: Re: Special note for CPP members




Martin W Sachs wrote:
> 
Hi Marty - some more comments inline.  I think we are all on the same
page as far as where we stand.  If it is acceptable to you and your
group,  I would like to start a new thread to start capturing the list
of issues implementors see for generationof CPA's.  Can we start this
ASAP?

> Duane,

> The key question is whether two different tools will produce EQUIVALENT
> CPAs.
>>>
Agreed.

> If the TP team does its job successfully, it should be quite clear from the
> specification what has to be in a given CPA composed from two CPPs.
>>>>>>>
This deliverable will be greatly appreciated by those who implement ;-)

> Remember that the two Parties should be installing identical copies of a
> single CPA, not producing separate CPAs from the same pair of CPPs. The
> latter is doomed to failure.  Aside from the additional complexities,
> unless
> both parties install identical copies of a CPA signed by both of them, they
> never can be sure that the two copies are truly identical.
>>>>>
Yes - I understand this issue.

 
> Regarding:
> 
>    It is the "same procedures" wording that causes the majority
>    of concerns.
> 
> Where is this discussion of "same procedures"?  I can't find it in either
> the current
> CPA-CPP specification or the TA specification.  It sounds like a statement
> that
> needs work.  If you tell me where it is, I will do something about it.
>>> 
It was from your earlier email.  You said " Any tool that produces the
correct CPA works regardless of
whether vendor A's tool uses the same procedures as vendor B's tool."

That is why I asked about the meaning of "same procedures".  I think
this is the key phrase we need the subgroup to start working on.
Granted, delivering it in time for ebXML v 1.0 will not be likely.


> Any discussion on the composition/negotiation topic needs to be in view of
> the whole TP team,
> so there is no (if not negative) value to keeping the
> composition/negotiation discussion separate.
> Remember that the first goal must be to guide the CPP-CPA specification
> into being complete
> and precise enough  such that any pair of CPPs that specify compatible
> function can be
> composed into a correct CPA by anyone's tools.
>>>>>>>>>>>>>>

Agreed. Maybe it is time to start a new thread entitled "CPA Negotiation
Issues Discussion". 

Duane Nickull


[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