Change Log
Public-Review Comments to TP Specification, ver. 0.911
Commenter: Mike Rawlins, Rawlins EC Consulting
1. Comment Type: Technical
Issue: Support test and production modes
Discussion:
If the Message-Service specification had provision for test mode, the CPP and CPA would support the Messaging-Service functions. At the moment, the Messaging-Service specification does not support test mode, so neither do the CPP and CPA. The consensus is that the Parties should establish a separate CPA for test mode and nothing is needed inside the CPA.
This can be revisited after Vienna. There are various ways of defining test vs. production mode in the CPA but first we would need to understand what organizations that use test mode vary between test and production and what they want to keep the same between test and production.
Resolution: no change
Commenter: Zongwei Luo, IBM
2. Comment Type: Technical
Issue: A role is responsible for the entire conversation. It may be appropriate to introduce a namespace for roles.
Discussion:
The collaboration role is associated with a specific role within the BP specification. IN a CPA, there is one CollaborationRole element for each Party and each is associated with a different role in the BP specification. The xlink to the Process Specification document is sufficient to define the equivalence between the role names in the two documents.
Resolution: no change
3. Comment Type: Technical
Issue: Very few lines are spent on error handling; an error messaging spec is needed.
Discussion:
Error detection is partly the responsibility of the business process and partly the responsibility of the message service. Error messages at the business level are specific cases of response messages and are interpreted at the business process level. Error messages detected by the messaging service are defined in the message specification and are sent to the "error" endpoint defined in the CPA. No additional error handling function is needed in the CPA.
Resolution: no changes needed.
- Comment Type: Technical
Issue: Why are CPPs not assembled into a CPA using the rules in the Core Components specification for the application of XML-based assembly and context rules? You should also consider that a CPA might be in the core.
Discussion:
The referenced specification is for building business documents from core components. Building a CPA from two CPPs is a very different process involving an element by element comparison of the two CPPs. Appendix F discusses this process. It is well understood that a CPA template might be a core component but it was agreed not to include a CPA template in a normative specification.
Resolution: no change.
- Comment Type: Technical
Issue: The CPP does not have a link to the Core Components Catalog specification. The BP should adopt using the naming convention in creating the CPP/CPA.
Discussion:
The CPP instance document does not need a connection to the Core Components specification or to any core components in a registry. The CPP may or may not be initially built from a core component or core components but once it has been built, it is actually a stand-alone document. The comment about the BP team should be directed to the BP specification.
Resolution: no change.
- Comment Type: Technical
Issue: What defines the dictionary entries for CPP if this is not the role of this document?
Discussion:
The role of the CPP-CPA specification is to define the contents of the CPP and CPA. If the Core Components team wishes to treat the CPP as a core component or define core components that can be combined into a CPP, which is within their scope. As mentioned under comment 5, there is no need for a link from a CPP instance document to the Core Components specification. Reference [EBXMLCC] is a textual reference to the Core Components specifications.
Resolution: no change.
1
Pub.Rev.TP.0.911.changes3/30/01 1:46 PM