IIC question for CPPA group: to be discussed Oct 28 teleconference

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

[Original thread in the ebXML IIC list archive. ]


>3. In Notes Section or with Business Transaction Characteristics (i.e. 
>tp:timeToPerform), suggest you indicate this relates to the business 
>transaction activity rather than the business collaboration as whole 
>(verify with Moberg and Schlegel).
>
><JD> isn't that obvious per the parent element "Business Transaction"?
I
>added a clarification note, though, in 3.3.1.
>
mm1: It is a limitation of CPP/A that only partially can recognize and 
handle timeToPerform exists (even in ebXML BPSS v1.05) at both the BTA 
and Business Collaboration levels. I would say that you can't infer 
anything.

I looked back at CPP/A v2.0 and now on v2.1 references the timeToPerform

actually for the Business Collaboration. So, I correct myself (sorry for

any confusion). It is a value in the CPP/A that cannot be overridden, is

used for sync reply and is not for a business transaction. Dale can shed

light here if he would.

In addition, this requires correction for v2.1 draft Dale as only an 
attribute is specified (not element that maps to the process). What the 
boundary is for CPP/A should be clearly specified (or constrained to) as

it relates to what is described in the process - for the profile and for

CPP/A v2.1

>Cheers,
>Jacques
>
>-----Original Message-----
>From: Monica J Martin [mailto:Monica.Martin@Sun.COM] 
>Sent: Monday, October 17, 2005 10:58 AM
>To: iic
>Cc: Jacques Durand
>Subject: IIC 10/17/2005: CPA Profile (Comments)
>
>Jacques,
>CPA profile comments:
>
>3.2.1
>1. In the Notes section, suggest you relate the conversation
concurrency 
>limits to whether or not it is allowed in the process specification. 
>Implementer's hint
>
>3.4.1
>1. uuid and nameID are not the same in ebBP (ebXML BPSS) so reference 
>should be to uuid only.
>
mm1: Here is what I found looking at the CPA specification and schema 
v2.0 and the ebXML BPSS v1.05 schema:

    * CPA v2.0 (Section 8.4.4.5 and both v2.0 and v2.1 schemas)
          o The uuid is implied. However, if BPSS applies, the uuid must
            be used.
          o Also includes ds:Reference and xlink:href for URIs.
    * ebXML BPSS v1.05
          o The uuid is required for the ProcessSpecification element.
          o ProcessSpecification element also includes a Documentation
            element in complexType that has a name attribute group (of
            name [required] and nameID [optional]).

 From what you indicated, I am uncertain RosettaNet was consistent in 
the usage identified above. I believe then that the uuid should be used 
in Section 3.4.1 for CPA Deployment Template Profile.

>2. In the Notes section, suggest you indicate that role changes will be

>supported in a latter version (via the definition of another 
>collaboration role). What this entails is that an abstract partner 
>assumes many roles within a process and as specified in a CPA. For 
>example, in negotiation, a buyer may be a requester and responder given

>whether he is providing an offer or counter offer.
>  
>
mm1: I've attached the negotiation instance we used as an example (for 
ebBP). What you have is a BTA where a Party (PartyInfo) can take on 
multiple roles within a Service. See how this is described in 
extensibility section of v2.1 CPP/A on how to handle this until a major 
change was anticipated in CPP/A (next major version). There hasn't been 
a syntactic change per se but the concern exists in v2.0 and v2.1 on how

to effectively handle it. This is why I suggested a note as a guide to 
implementors.

 From v2.1 CPP/A:


      1.1.1 Role

In [ebBPSS2], new constructs are introduced to track */Role /*values 
through complicated /Business Collaborations /(choreographies). An*/ 
ExternalRole /*element allows global values to be declared that 
*/Performs /*elements then associate with */Role /*values in toplevel 
/Business Collaborations. /Likewise, */Performs /*elements are used 
within a */CollaborationActivity /*to associate the current /Business 
Collaboration's *Role */values with the declared */Role /*values within 
a referenced /Business Collaboration. /As a result, one Party may be 
associated with multiple values even within the same service. For the 
CPPA 2.1 maintenance release, this means that when different */Role 
/*values */ /*within */Services /*are described, then new 
*/CollaborationRole /*elements will be needed.

NOTE: When a new major version of ebXML CPPA is warranted, it is likely 
that the organization of the */CollaborationRole /*element within CPPA 
will undergo considerable "flattening" and refactoring to conform to new

understandings of /Service, Role, /and /Action./

This isn't resolved (AFAIK) by PartyInfo.

>3. In Notes Section or with Business Transaction Characteristics (i.e. 
>tp:timeToPerform), suggest you indicate this relates to the business 
>transaction activity rather than the business collaboration as whole 
>(verify with Moberg and Schlegel).
>  
>
mm1: See previous comment to your response Jacques.

>3.5.1
>1. May need to specify that a default channel must be specified to 
>handle acknowledgements, status messages, errors, etc.
>  
>
mm1: Already resolved.

>General
>1. May need to discuss to what extent process specification override is

>assumed in CPA. This question is more pervasive than CPA v2.0.
>  
>
mm1: You asked for a few sentences here on override that may be used in 
Section 4 for interpretation subsection. If we need to explain this more

fully, please let me know. The key, I think, is to notify users that the

cases of override could happen, should be understood, and the parties' 
prepared for the after-effects.

I propose we add this to the table form to this point:

When used with the ebBP specification, some process definitions created 
by the user community may be overridden by some values in this CPA. For 
example,
1. A weak form of non-repudiation may be allowed, despite the parties' 
expectations expressed in the business process. By enabling the use of 
signed Acknowledgment for reliably delivered messages, a weak form of 
non-repudiation of receipt can be supported. This is considered weaker 
than the Receipt Acknowledgment signal because no schema check can be 
performed on the payload prior to the return of the Acknowledgment.

2. The ackSignatureRequested attribute can be set independent of the 
value for the isNonRepudiationReceiptRequired attribute under the 
BusinessTransactionCharacteristics element (associated with the business

process).

Thanks.

>2. Some of these comments may be handled at the end when you discuss 
>rationalization between messaging, profile and process in Section 4 
>(operational profile).
>