CPP/A 10/14/2005: Starting Comments on v2.1 Working CPP/A Draft

[Monica J Martin <Monica.Martin@Sun.COM>]

Through page 50.....editorial are marked as such. More may follow. Thanks.

[start]
Section 7.3:
May wish to consider reference to CPA profile in IIC deployment template 
- indicative of idea of CPA template

Section 7.5
EDITORIAL: You specify middleware. As we discussed in ebBP, this may be 
services, gateway, etc. Suggest more generic language.

Section 8.4.4
EDITORIAL: With the updates in ebBP, may wish to call consider updates 
similar to signals: ProcessSpecificationInfo (particularly if you are 
generalizing).

Section 8.4.4.2
EDITORIAL:
Change from: NOTE: The ebXML Business Process specifications with a 1.*  
major version have a version indicating the version of the 
Process-Specification document; in major version 2, the 
specificationVersion attribute indicates the version of  the 
Process-Specification document. An instanceVersion is added to track 
versioning of specific business process descriptions.
Change to: NOTE: The ebXML Business Process specifications with a 1.*  
major version have a version indicating the version of the 
Process-Specification document; in major version 2, the 
specificationVersion attribute indicates the version of  the 
Process-Specification document (the technical specification itself). An 
instanceVersion is added to track versioning of specific business 
process descriptions, such as those in the context of a particular domain.

Section 8.4.4.6
1. This discusses verification that the Process Specification has not 
changed (via the signature).  How is this approached if an external 
service provides the values for the late binding (For example, at this 
time, this is constrained to time to perform in ebBP although this could 
be expanded). This circumstance likely is not constrained to the ebBP 
case (reference perhaps policy).

2. Shouldn't this be generalized if another process spec is used?
EDITORIAL:
Change from: "After applying any transforms, it would be necessary to 
validate the transformed document against the ebXML Business Process 
Specification Schema[ebBPSS]."
Change to: After applying any transforms, it would be necessary to 
validate the transformed document against the process specification, 
such as the ebXML Business Process Specification Schema[ebBPSS] if used.

3. Note on 2., a global change may be required for any reference of 
ebBPSS to generalize. I didn't go to the specificity of referencing them 
all.

Section 8.4.5
What considerations are needed for CPA to support MPC?

Section 8.4.5.3
What if the location changes for the URI? Is another references also 
required (related to ebBP questions from UBL) or is this handled by the 
validation ahead of use of the CPA? This question may be broader than 
this section alone. It appears from discussion in September 2001, that 
there was a caveat that validation may occur regardless if the CPA was 
signed and exceptions raised. I currently don't (at least yet) see this 
constraint in the current specificatin, if still applicable
(see: 
http://lists.oasis-open.org/archives/ebxml-cppa/200109/msg00044.html, 
for example)

Section 8.4.8
1. What happens if several delivery channels are used within a process 
specification?
ref: "The ServiceBinding element identifies a DeliveryChannel element 
for all of the business Message traffic that is to be sent or received 
by the Party within the context of the identified Process-Specification 
document.  It MUST contain at least one CanReceive or CanSend child 
element." Is this construed to relate to multiple endpoints with 
different channelID within a DeliveryChannel rather than multiple 
DeliveryChannel? If it is the former, this isn't an issue.

See: ...
- <xsd:complexType name="CollaborationRoleType">
- <xsd:sequence>
  <xsd:element ref="tns:ProcessSpecification" />
  <xsd:element ref="tns:Role" />
  <xsd:element name="ApplicationCertificateRef" 
type="tns:CertificateRefType" minOccurs="0" maxOccurs="unbounded" />
  <xsd:element name="ApplicationSecurityDetailsRef" 
type="tns:SecurityDetailsRefType" minOccurs="0" />
  <xsd:element ref="tns:ServiceBinding" />
  </xsd:sequence>
  </xsd:complexType>
...

Should there not be more than one service binding (particularly if many 
services are used across a process specification (for example, as 
defined by the OperationMapping if using ebBP)? Note, earlier this year 
March 2005, CPP/A and ebBP team discussed this is logically a business 
service rather than a lower level service. At that time we identified 
that a process specification could encompass many services; the 
CollaborationRole could have multiple service bindings. In that 
discussion, the (business) service was seen as the scope of all the 
canSend and canReceive in an ActionContext.  I am uncertain these 
changes have been fully integrated into the current schema.

Section 8.4.10, .11
Are there any changes required if we integrate the pull-functionality 
into CPP/A v2.1 (descriptive change only)?

Section 8.4.12
1. EDITORIAL:
Change from: NOTE:  An implementation MAY provide the capability of 
dynamically assigning delivery channels on a per Message basis during 
performance of the BinaryCollaboration. The delivery channel selected 
would be chosen, based on present conditions, from those identified by 
CanSend elements that refer to the BinaryCollaboration that is sending 
the Message. On the receiving side, the MSH can use the distinct 
EndPoints to identify the DeliveryChannel used for this message exchange.
Change to: NOTE:  An implementation MAY provide the capability of 
dynamically assigning delivery channels on a per Message basis during 
performance of the Business Collaboration. The delivery channel selected 
would be chosen, based on present conditions, from those identified by 
CanSend elements that refer to the Business Collaboration that is 
sending the Message. On the receiving side, the MSH can use the distinct 
EndPoints to identify the DeliveryChannel used for this message exchange.

2. EDITORIAL: Subsequent to 1. , may need a global change in CPP/A 
specification where BinaryCollaboration is referenced. A general 
statement upon first reference might make it easily fixed and then 
globally updated. This also holds true to similar references in the 
CPP/A schema.

3. Note: Also see comment on Section 8.4.5.

4. At some point in the future, may wish to consider if a combined 
approach is used where it is know whether or not a business transaction 
is or isn't used in more than one context (reuse question) and 
accommodate both together in the CPP/A. The sections that talk about 
this variability (at least to me) are somewhat confusing. The model of a 
business transaction is that it is reusable.

Section 8.4.14.3
EDITORIAL:
Change from:
The isConfidential attribute has the possible values of "none", 
"transient", "persistent", and "transient-and-persistent". These values 
MUST be interpreted as defined by the ebXML Business Process 
Specification Schema[ebBPSS].
Change to:
The isConfidential attribute has the possible values of "none", 
"transient", "persistent", and "transient-and-persistent". These values 
MUST be interpreted as defined by the process specification such as 
ebXML Business Process Specification Schema[ebBPSS], when used.

Section 8.4.14.10
If this is true:
"When synchronous reply mode is in use (see Section 8.4.23.1), the 
TimeToPerform value SHOULD be used as the connection timeout."
Then the CPP/A needs to deal with the fact that the TTP is not static 
and could be acquired and bound at runtime (thus establishing the 
timeout parameter). Verify, if applicable, this is handled or identified 
as subject to future changes.

Section 8.4.16
EDITORIAL:
Change from:
The ActionContext element has the following elements:
zero or one CollaborationActivity element,
zero or more [XML SCHEMA-1] wildcard elements.

The ActionContext element also has the following attributes:
a REQUIRED binaryCollaboration attribute,
a REQUIRED businessTransactionActivity attribute,
a REQUIRED requestOrResponseAction attribute.

NOTE: See Section 10.6 for a description of the ActionContext2 element 
that is used for Process Specifications conforming to [ebBPSS2].

Change to:
The ActionContext element has the following elements:
zero or one CollaborationActivity element,
zero or more [XML SCHEMA-1] wildcard elements.

The ActionContext2 element also has the following attributes:
a REQUIRED businessCollaboration attribute, [1]
a REQUIRED businessTransactionActivity attribute,
a REQUIRED requestOrResponseAction attribute.

NOTE: See section 10.6 for a description of the ActionContext2 element 
that is used for Process Specifications conforming to [ebBPSS2].

[1] See previous comment on Section 8.4.12 related to change of name of 
BinaryCollaboration. Same holds true for Section 8.4.16.1, 8.4.16.2, 
etc. (like I said, global change may be required).
[end]