Subject: RE: initial draft of CPP-CPA Specification
Stefano, Thank you very much for your comment set. If I do not reply to a particular comment, it means that I agree. Responses are embedded in this copy of your comment set. My replies are embedded in the attached copy of your comments. To all: most comments that you supplied so far will be processed AFTER I complete and distribute the initial draft of the CPA chapter. Regards, Marty (See attached file: response-stefano.html) ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* Stefano POGLIANI <email@example.com> on 01/17/2001 09:37:58 AM To: firstname.lastname@example.org, email@example.com cc: Subject: RE: initial draft of CPP-CPA Specification Please disregard the previous mail since the attachment was poorly formatted! ============================================================================ == Attached you will find my comments on the document. Please do not hesitate to contact me for clarifications on my comments. Best regards and congratulations for the excellent job! /Stefano » -----Original Message----- » From: Martin W Sachs [mailto:firstname.lastname@example.org] » Sent: 15 January 2001 23:11 » To: email@example.com; firstname.lastname@example.org » Subject: initial draft of CPP-CPA Specification » » » I have attached the initial version of the CPP-CPA specification. As » previously indicated to the TP team, this copy has the CPP chapter but not » the CPA chapter. Please review the CPP chapter while I am completing the » CPA chapter. Please post comments and be prepared to discuss at » Wednesday's conference call. » » Regards, » Marty » » (See attached file: cpa-cpp-spec-0.1-interim.pdf) » » ****************************************************************** » ******************* » » Martin W. Sachs » IBM T. J. Watson Research Center » P. O. B. 704 » Yorktown Hts, NY 10598 » 914-784-7287; IBM tie line 863-7287 » Notes address: Martin W Sachs/Watson/IBM » Internet address: mwsachs @ us.ibm.com » ****************************************************************** » ******************* »
Comments to the TPA specification V0.1 (January 15, 2001)
"..with another business partners" should be changed into "...with another business partner"
"...between two Partners" should be changed into "...among Partners".
MWS: A CPA among more than two parties is major new function. I do not
believe that we can address this in phase 1 (i.e. before May, 2001). I
prefer to delete places in the CPP-CPA specification that refer to more
than two parties. This applies to all subsequent comments about more than
"...of the two Partners' TPPs" should be changed into "...of the Partners' TPPs".
this NOTE should state that, whilst in principle TPA/CPA are among two OR MORE Partners/Parties, it has been decided that the scope of this specification will concentrate on TWO Partners/Parties.
This note will avoid further confusions, during the remaining part of the doc, about the use of TWO instead of MANY.
Shouldn't also "security constraints" be mentioned here ?
I think "xxxx" stands for the name of the current document.
I like very much this section (which is missing from the TA document and which causes a lot of troubles when reading the TA....).
But I would make sure that a pointer to the "OFFICIAL" ebXML Glossary is made.
I would change the first sentence as follows : "A business process that is carried out and managed by all the participants".
These empty lines should be removed for consistency with the other items
"...to carry out a Collaborative Process" should be changed into "...to carry out the Collaborative Processes"
"comma" after "logically" is not required
"Collaboration Protocol" should be changed into plural "Collaboration Protocols"
It is a little bit difficult to read that "a Service is the representation of a set of services...".
I would say "A Serive is the representation of a set of functionalities..."
"..the chosen business process" should be changed into "...the chosen Collaborative Process".
I would modify the sentence "Both parties...systems" with the following:
"The agreed upon CPA can be used to configure the runtime system of each intervening party".
The reason is that the concept of CPA=configuration-file is introduced.
I would add to this sentence that it is important that each party knows the other party's ROLE in the Collaborative Process,l not only the Collaborative Process
I would enclose "within a TPP" in parenthesis since, otherwise, one may not understand if it is the CPP or the TPP to be stored in the repository
I would change the part from "This specification..." until "...XML documents." with the following : "This specification defines the XML vocabulary for creating electronic CPPs and CPAs".
I would change the part from "In the appendices..." until "...Schema document" with the following : "In the appendices of this specification sample CPP and CPA documents, with their associated DTD and XML Schema files, are provided."
I would enforce the idea, here, that the "legal terms", which cannot be easily expressed in any electronic document and that are not directly implied in the configuration of the software to manage the exchange, are intentionally left outside the CPP.
The concept is there, but I found it difficult to read. There is too much use of the terms "business process" to qualify both internal and external. I propose this wording:
"A CPA describes all the valid, visible (and, hence, enforceable) interactions between the parties and is independent of the internal processes executed at each Party. Each Party executes its own internal processes (which are, normally, invisible to other parties) and interfaces them with the Collaborative Processes described by the CPA.
The intent of the CPA is to provide a description that can be easily comprehended by humans and yet is precise enough for enforcement by computers."
I would change the sentence "The conversation..." until "...the business process" with the following : "The conversation represents a single unit of business as defined by the business process; a new conversation is created each time a new unit of business is started."
If accepting the previous comments, the whole sentence "When the business... " until "..unit of business." should be removed.
Unuseful empty line
I would change the part "...and invoke the application-specific programs" into "... and interface with the Party's back-end processes"
"For a CPA written in terms of roles, ...". I think this sentence is introduced without any explanation of what it really means. I would say something like this:
"In some circumstances, a CPA may be created that refers to abstract roles instead than to physical partners. In this case, it is recommended...."
I do not understand what this really means. I think an example would make it clear.
I STRONGLY DISAGREE. Why, for once, don't the US convert things to their own convention?
MWS: This will happen when the US converts to metric.:-)
Outside of joking, I think Internationalization is required here for the following reasons:
Again, let's try not to impose any US-based constraint.
Again, let's try not to impose and US-based constraint.
Besides, the US format for the date is not so suitable for sorting algorithms...
I would add a 3 characters indicator of the time zone (such as GMT, CET, EST, PST etc)
I would change "...and the business-application functions..." into "...and the back-end functions..."
MWS: I don't think I agree. I view "business application
functions" as the application as described by the BP metamodel. It
is aware of the collaboration and of the back end processes. I view
"back end processes" as functions such as database, ERP, workflow, etc.
Their view is strictly internal to one party.
I would re-use the first part of section 8.6 since it is, in my opinion, more clear. Thus:
"A Delivery Channel is THE combination of a Transport Layer definition and a Document Exchange definition, with some additional properties to define security and addresses, that describes tha Party's message-receiving characteristics. Several Delivery Channels can be defined in a CPP."
Sorry to post this comment now (which is late on respect to when you submitted the CPP DTDs...).
I would have thought to the <ROLE> tag as a subtag of the <CollaborationProtocol> tag. In fact, in my understanding, a role has a meanin ONLY in the context of the CollaborationProtocol it refers to.
Besides, the <ServiceBinding> tag (lines 506 to 513) seems to be a duplication of the xlink attribute in the <CollaborationProtocol> tag
MWS: See recent discussions about this on the TP list.
I would change "A delivery channels is a combination..." into "A Delivery Channel is the combination..."
It is not just "a" combination, but "that well-defined combination" you are describing.
MWS: A party may define more than one delivery channel.
Each would describe different capabilities. "the combination" implies
that there is only one combination. "a combination" allows for more
I would make explicit that the Delivery Channel has some other property:
"A Delivery Channel is the combination of a Transport layer definition and a Document Exchange definition, with some additional properties to define security and addresses, that describes the Party's message-receiving characteristics."
MWS: security and addresses are inside the transport and document
exchange definitions. Therefore, they are implied by the present text.
It is not necessary to be so detailed in this brief introductory section.
I think that "The same delivery channel or the same..." should be changed into "The same Document Exchange definition or the same..."
MWS: Thank you for pointing out this typo.
Again, sorry for being late to highlight this comment. Wouldn't it be cleaner if the <ServiceBinding> tag would actually be a <CollaborationProtocol> tag which references (IDREF) the <CollaborationProtocol> tag defined at lines 391-393 ?
The issue is that the "xlink" to the BP definition is present in too many places with the risk of inconsistencies.
MWS: See more recent discussion on the TP list. The final form
is still to be decided.
If I understand correctly, the reason for having more than one endpoint is to allow each endpoint to deal with a different purpose. If I understand, the purpose is the same as the "type", i.e. "Login, request, response, error".
I am not clear if "no encoding" is the same as "encoding with no options".
MWS: I should clarify the words. "encoding with no options" is supposed to mean that the transport protocol decides whether and how to encode and the upper level is not given the choice.
If <Transport Encoding> is omitted, would the default apply (no encoding) ?
MWS: If <TransportEncoding> is omitted, the default is whatever
the transport protocol normally does. If the transport protocol does no
transformation, that is "no encoding".
I am not clear on the first sentence of this NOTE.
<TransportEncoding> is under <Transport>. I never saw <Communication> so far.
MWS: typo inherited from tpaML.
I assume that the <TransportTimeout> structure is managed by the MSH only, am I right ?
MWS: In the last conference call we agreed to eliminate <TransportTimeout>.
The consensus is that any timeout performed directly by the transport implementation
does not need agreement between the parties and the important timeout is
the reliable messaging timeout.
Does this sentence mean that the "endpoints" defined in the CPP may be dynamically redefined by information exchanged during a Conversation?
MWS: That is correct. Some existing B2B protocols do this.
I believe that cXML is one such case.
I would rather use a fictitious name instead of a real one.
MWS: I will fix if Chris agrees :-) Actually, it will be
hard to find a fictitious name that no one will later claim as his/hers.
I would change "...wil not be used for this CPAs composed from this CPP." into "...will not be used for any CPA composed from this CPP.".
"...the certificate to be used in this delivery channell by...".
Here we are not talking about Delivery Channels, so I do not understand what "THIS delivery channel" points to.
The sentence "The protocol, protocol version..." until the full-stop does not read very well for me. There is something missing or a cut/paste problem.
MWS: It should say "...version, and certificate reference must
be supplied. Examples..."
Saying that "the Document Exchange section of the CCP defines the properties of the messaging service to be used..." implies that this is the only place ("THE properties") where the messaging service characteristics are defined. I do not think that this is what is meant here. In fact there are a couple of considerations:
Not being an expert in this domain, I would be happy to understand the difference between the <MessageEncoding> tag here and the <TransportEncoding> tag described at lines 662 and following.
MWS: I believe this is clear. Line 908 defines <MessageEncoding>.
<TransportEncoding> is defined in line 663. I think this is another
case of confusion between "Transport" and "Message Service".
If the <ReliableMessaging> tag is completely missing, does this mean that a "deliverySemantic=BestEffort" is applied ?
MWS: This question is open. One view is that <ReliableMessaging> should be a required tag. Another view is that the cardinality of <ReliableMessaging> should match the cardinality of RM in the messaging service spec.
I would add a comment on the precedence/overwriting between these timeout parameters (BP based) and the Transport-related timeout parameters
MWS: As I mentioned above, the transport timeout tags are being
I found two references to the <ServiceBinding> tag: one at line 506 and the other at line 608. None of them, in my understanding, references the <CollaborationProtocol> ID, but they both reference the "xlink" attribute mentioned within the <CollaborationProtocol> tag. This is one of the reasons I proposed changes in some previous bullet.
MWS: See recent discussion on the listserver.
eList eXpress LLC