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 » ****************************************************************** » ******************* »Title:
Line 5 (typo)
"..with another business partners" should be changed into "...with another business partner"
Line 7 and Line 8:
"...between two Partners" should be changed into "...among Partners".
"...of the two Partners' TPPs" should be changed into "...of the Partners' TPPs".
At this point I would add a NOTE:
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.
Line 14 and 15:
Shouldn't also "security constraints" be mentioned here ?
Line 51 (typo)
I think "xxxx" stands for the name of the current document.
Lines 58 thru 94.
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.
Line 64 and 65.
I would change the first sentence as follows : "A business process that is carried out and managed by all the participants".
Line 76 and 79 (typos)
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"
Line 84 (typo)
"comma" after "logically" is not required
Line 88 (typo)
"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.
Lines 113 thru 116.
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
Line 125 and 126.
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".
Line 126 and 127.
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."
Paragraph between Line 129 and 135.
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.
Paragraph between lines 144 and 150.
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."
Line 153 and 154.
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."
Line 157 to 159.
If accepting the previous comments, the whole sentence "When the business... " until "..unit of business." should be removed.
Line 160 (typo)
Unuseful empty line
Line 177 and 178.
I would change the part "...and invoke the application-specific programs" into "... and interface with the Party's back-end processes"
Line 180 and 182 (typo)
"...a CPA from two nor..." should be "...a CPA from two CPPs nor ..."
Line 187 (typo)
"...these notes server to..." should be "...these notes serve to ..."
"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...."
Bullet between line 256 and 259.
I do not understand what this really means. I think an example would make it clear.
Note between line 263 and 266.
Why method names are not sensitive?
What is the CPA-tool which maps names into quantities?
Lines 280 thru 286.
I STRONGLY DISAGREE. Why, for once, don't the US convert things to their own convention?
Outside of joking, I think Internationalization is required here for the following reasons:
for the social agenda of ebXML. Privileging US means privileging the "rich" and "big" as opposed to the "poor and small"
technically, if there is the need of ad-hoc conversion in the runtime, the same software cannot run everywhere in the world.
Line 289 and 290.
Again, let's try not to impose any US-based constraint.
Line 300 thru 304
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...
Line 307 thru 309
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..."
Line 336 and 337.
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."
Paragraph between lines 339 and 344.
In this paragraph the "fan-out" situation is described. Is it possible for the "Document Exchange Layer" to participate in a "fan-in" situation (from Transport to Collaboration-Protocol Layer) ?
I would modify the sentence "The options...the Transport layer" into the following : "The options selected for the Document Exchange Layer are complementar to those selected for the Transport layer."
Line 489 thru 513
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
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.
Line 542 and 543.
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."
I think that "The same delivery channel or the same..." should be changed into "The same Document Exchange definition or the same..."
Line 570 thru 572 AND 608 thru 611.
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.
Line 650 thru 660.
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".
If this is the case, I would add a little sentence with an example
How do I specify a Party where the same endpoint can be used for more than one (but not all) of the above purposes?
Line 668 to 670.
I am not clear if "no encoding" is the same as "encoding with no options".
If <Transport Encoding> is omitted, would the default apply (no encoding) ?
Line 673 to 675.
I am not clear on the first sentence of this NOTE.
What is meant by "business application process"? It is the legacy or the Collaboration Protocol layer?
Which are the "data which determine the encoding requirements" ?
I think that a little example would make it more clear
Line 679 and 680.
<TransportEncoding> is under <Transport>. I never saw <Communication> so far.
Line 682 thru 704.
I assume that the <TransportTimeout> structure is managed by the MSH only, am I right ?
Line 727 thru 729.
Does this sentence mean that the "endpoints" defined in the CPP may be dynamically redefined by information exchanged during a Conversation?
I would rather use a fictitious name instead of a real one.
Line 792 and 793.
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.
Line 819 to 821.
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.
Line 885 and 886.
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:
By "messaging service", do we mean the same as
If not, we should introduce what we mean by "Messaging Service" here.
If yes, we had other places where we have been defining properties for the Transport.
I would try to qualify here WHICH kind of properties are specified in this place and WHY they are specified here and not elsewhere.
Line 907 thru 913
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.
Line 926 thru 931.
If the <ReliableMessaging> tag is completely missing, does this mean that a "deliverySemantic=BestEffort" is applied ?
Line 956 thru 964.
I would add a comment on the precedence/overwriting between these timeout parameters (BP based) and the Transport-related timeout parameters
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.
I did not go through the appendices, trusting that they conform to what has been written in the specification.
eList eXpress LLC