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:mwsachs@us.ibm.com] » Sent: 15 January 2001 23:11 » To: ebxml-tp@lists.ebxml.org; ebxml-ta-security@lists.ebxml.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".
Line 9:
"...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
Line 83.
"...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"
Line 93.
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..."
Line 99.
"..the chosen business process" should
be changed into "...the chosen Collaborative Process".
Line 100.
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
Line 119.
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)
empty lines
Line 184.
"...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 ..."
Line 244.
"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)
Line 334
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
Line 542.
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."
Line 546.
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?
Line 746
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.".
Line 805.
"...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
"Transport" ?
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
Line 1029.
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.
Powered by
eList eXpress LLC