ebXML TA document feedback

[Jeff.Suttor@eng.sun.com]

Attached is feedback on the current ebXML TA document from Stefano & Karsten.

--
Jeff.Suttor@Sun.com
- general:
use lower case for the MAY's, SHOULD's, etc. as appropriate.
only italics glossary terms at first mention.

- section 2:
please add stefano.pogliani@sun.com

- section 5.1, paragraph 3:
Remove the reference to "object oriented". I would read the sentence as :
"...XML might enable more open, more loosely coupled, and more component-oriented systems than EDI".

- figure 1:
text on box one in figure 1 should say retrieve definition of business process
and information model (business details is too vague)

- section 6, list item 3:
The Business Service Interface (whichever thing they mean since it is NOT referenced in the Glossary) is not stored in the RegRep so it cannot be discovered. What is probably meant here is the "CPP".

- section 6, paragraph 4:
sales tax calculation is not a good example, use purchase order
exchange

- section 6, paragraph 5:
The sentence starting with "Company A knows that..." should be moved BEFORE section 6, paragraph 4, (or, eventually, totally removed since it does not add too much to the context)

- section 6, paragraph 6:
"that the scenario ...". Repetition.

- section 6, paragraph 6:
This implies that there is some form of Automatic Negotiation and that the ebXML software is capable of managing it. 
This has never been specified in the documents and, thus, is completely arbitrary. This should be restated assuming that the negotiation is performed by humans.

- section 7:
is unnecessary. There are mismatches in naming relative to what
metamodel uses for names. And there is no FSV in ebXML, unless you consider TP
and TRP the FSV. There is no FSV in N90 either, as far as I know. Please tell
me who benefits from reading chapter 7. Figure 3 of chapter 7 is reasonable,
probably belongs in BP chapter.

- section 7.1, paragraph 1:
The sentence "This model is based upon..." should be a footnote.

- section 7.1, paragraph 2:
"...FSV serves as a reference that MAY be used..."
Why "MAY" ? Either it does or does not. My take is that "it does", so, do not use "MAY".

- section 7.1, paragraph 3:
Instead of "decomposed" I would use "grouped". A Business Process groups a set of activities (coordinates them) and a BP can be decomposed in the constituing activities. The viceversa is false, in my opinion.

- section 7.1, paragraph 6:
From the glossary "Service Interface : A description and binding for an automated process". I do not understand how does this fit here (simply do not understand, no disagreement since I do not catch the point)

- section 7.2:
This whole chapter requires some more explanation. I do not understand the relationship between "Core Library" and "Business Library" and their different usages. I do not understand what "Business Objects" are nor what they are for.

- section 7.2, paragraph 1:
The sentence seems not logically terminated. If the modelling techniques are not mandatory requirements, why are they described here? So, if this sentence shold be kept, also explain why these techniques are described anyway.

- section 7.2, paragraph 3:
The reference to "Core Library" in this line should probably be "Business Library"

- section 7.2, paragraph 4:
"Class Diagrams will capture..." + "The class diagram is a free..."
Where are "Class Diagrams" in the Figure 3 ?

- section 7.2, paragraph 6:
The whole paragraph is not clear to me. I do not understand what "Business Objects" are (not defined in the Glossary nor previously introduced) nor what they are for. 

- figure 4:
The bottom area of Figure 4 is not clear. The dotted arrows "CPP derives" and "CPA Governs" are incorrect for me.

- section 7.3, paragraph 1:
"e.g. XML DTD, Schema etc" should be replaced by "according to XML DTD, Schema etc".

- section 7.3, paragraph 1:
All the sentence from "In order to enable...SHALL be retrieved." has to be removed. NO GUID/UID discussion in the Technical Architecture.

- section 7.3, paragraph 1:
replace word methodology with fashion

- section 7.3, paragraph 2:
From "Existing Business Process... " to end of line 422 has to be removed. NO GUID/UID discussion in the Technical Architecture.

- section 7.3, paragraph 3:
The sentence "A UID Reference...reference mechanism" has to be removed. NO GUID/UID discussion in the Technical Architecture.

- section 7.3, paragraph 4:
"specifically" should be substituted with "also"

- section 8:
 is misplaced, it is logically an extension of the overview scenario.
There is  nothing magical about the 'phases'. It does not merit its own
chapter.

- section 8.2:
All this paragraph should be rewritten. To engage in ebXML it is NOT necessary to:

download the ebXML specs... (why should I have to do this? Isn't ebXML modular?)

Download the Core Library and the Business Object Library... (why am I forced to use the Core Components? Why should I download them (even if I want to use them) ? Couldn't I browse a remote repository where they are stored?)

"The Trading Partner MAY also request other Trading Partners' Business Process information (stored in it business profile) for analysis and review". 
The sentence does not mean too much in this context. I think here they simply want to say that a given Partner would like to know how other partners may play a role in a given BP and that this could be done by invesigating the relevant CPPs

"The Trading Partner MAY also submit its own Business Process information to an ebXML compliant Registry system".
I am lost. What is the "Business Process information" a partner would wish to submit? Perhaps the CPP ?

- section 8.2, paragraph 1:
The term "Business Service Interface" is used inconsistently. There is NO Automatic Negotiation.

- figure 5:
Where are the CPP/CPA in the right part of the Figure?

- section 8.3, paragraph 1:
The term "Business Service Interface" is used inconsistently. There is NO Automatic Negotiation.

- section 8.3, paragraph 1:
This implies that the ebXML runtime is able to talk to the RegRep. This is not a requirement nor, I think, a priority thing !!!

- figure 6:
Where are the CPP/CPA in the right part of the Figure?

- section 8.4:
This implies that the ebXML runtime is able to talk to the RegRep. This is not a requirement nor, I think, a priority thing !!!

- section 9.1.1, paragraph 1:
The CPP does not express the "Business Process" nor the "Business Service Interface" requirements of a given partner. It epxresses:

the role a partner plays in already define Business Processes

the choreography of the exchange defined by such Business Process

the technical infrastructure (protocol, security etc) able to support this

- section 9.1.1, paragraph 2:
The first part from "To facilitate ..." up to "...Collaboration Protocol Agreement (CPA)" is duplicated. It should be removed since it does not add anything new.
The second part "A CPA is a document..." is the only part that really serves.

- section 9.1.2, paragraph 1:
The Term "Service Interface" (from Glossary : "A description and binding for an automated process") is not really what is meant to be included here.

- section 9.1.2, paragraph 1:
No one ever said that a partner should only register ONE CPP. This is an arbitrary assumption from the Editor. I think, on the contrary, that big/medium organizations may submit more than one CPP.

- section 9.1.2, paragraph 1
- Change "MAY include" with "includes". 

- section 9.1.2, paragraph 2:
This paragraph is "almost" ok and replaces many of the previously defined things. The only crititicisms are:

The concept of ROLE in a Business Process, which is fundamental in mapping a BP into a given CPP, is not presented at all. The idea of ROLE should be included, I think

The use of "SHALL". I would avoid it, simply stating that "compliant Trading Partner registers..."

- section 9.1.3, paragraph 1:
I think that this should be a new Line. Then it does not relate these 3 layers with the CPP/CPA. Why are these layers presented here if they are not related to anything that concretely belongs to ebXML ?

- section 9.1.3, paragraph 2:
From "A CPA contains..." up to "...to conduct eBusiness." is repeated since the beginning. Remove this sentence.

- section 9.1.3 , paragraph 3:
"directory service" ????? What's this!!! It is RegRep full-stop!
 
- section 9.2.1, paragraph 2:
There is a fundamental contraddiction in this paragraph. No specific language is mandated but if one is chosen it should be UML!!!! This simply means : use UML!

- section 9.2.1, paragraph 2:
is misleading, the point is not whether to use UML or not, the point is
that ebXML provides a concise way of specifying a business process model
(specification schema) either as UML or as XML, your choice, they are
isomorphic. If you do not use the ebXML provided speficication schema, your
process will not be ebXML interoperable. The comments about using UML should
not be about modeling language, it should be about using UMM methodology
(which in turn mandates UML).

- section 9.2.2:
All this section is a Requirement section, not an Architectural section. The use of SHALL and MAY are too much confusing.....

- section 9.2.2 needs rewording

In a series of executive committee meetings Klaus, Bill and Ray all agreed to
use the term business information object, rather than just business object. We
should use this term everywhere. I cannot answer why the executive commitee
have not made this agreement publicly known: Business Information Object is
the identification of an information structure required in the modeling of the
enterprise and its business processes

- section 9.2.3:
I think this is not well explained. The first time I read it I thought "The BPP and the MetaModel are not linked with anything else in ebXML..."

- section 9.2.3,  paragraph 4:
Remove from "The mechanism for..." up to "...for each component.". Please no GUID/UID discussion in the TA document.

- section 9.2.3, paragraph 5:
This implies that the ebXML runtime is able to talk to the RegRep. This is not a requirement nor, I think, a priority thing !!!

- section 9.2.3, paragraph 6:
Remove "and therefore...GUID". Please no GUID/UID discussion in the TA document.

- figure in 10:
 is out of context, it was intended to show relationship
between core library and business library and then set the stage for context
based content. The cut and paste job was incomplete. 

- section 9.2.4:
The concept of "context", even if referenced many times, is confused and not explained.

- section 9.4 "Registry Functionality".
It looks like the "Registry and Repository" turned into "Registry full-stop".
Where is the presentation of the Repository Information Model worked out by Farrukh? This, I think, is very important since it defines the extensibility context of the Repository and its real value.

- figure 12:
The box labelled "Other Registry Service Interface(s): UDDI, CORBA" is, I think, OUT OF SCOPE of ebXML. 

- section 9.4:(yes, two pages long!):
All this section is a Requirement section, not an Architectural section. The use of SHALL and MAY are too much confusing....

- section 9.4.3:
What is really meant here? I thought that the Registry Interface was designed to be accessed by TR&P. If not (i.e. It could also be accessed by SOAP for instance) I think this would be a good place to state it explicitely.

- section 9.4.4:
Remove the two lines. Please no GUID/UID discussion in the TA document.

- section 9.5.1, paragraph 1:
Replace "SHALL provide" with "provides".

- section 9.5.2:
VERY IMPORTANT. The Messaging Layer should be independent from the CPA (otherwise the modularity of use would be broken...). So, the "Rules of Engament" are enforced by the layer ABOVE the Messaging Service (the layer implementing the CPA which is, in my vision, the Business Service Interface)

- section 9.5.2, paragraph 7:
The bullet "Logging". Is this really specified anywhere ?

- section 9.5.3, paragraph 2:
Replace "SHALL interface" with "interfaces"

- section 9.5.3, paragraph 3:
Replace "SHALL help" with "helps"

- section 9.5.4, paragraph 2:
Replace "MAY consist" with "consists"

- section 9.5.4, paragraph 2:
Why the "ebXML Message Envelope MAY be packaged using the MIME..." ? I thought that use of MIME was the default. I understand that if I have only 1 part, I would not need MIME multipart, but this is not the same as I read the previous sentence. It appears (from reading it) that MIME is one of many possibilities, which is not.

- section 10.1, paragraph 1:
"The clause specified..." needs to be replaced by "The clause specifies..."

- section 10.1, paragraph 3:
I tend to disagree with that sentence. Interoperability is achieved via conformance to the Specifications more than to the Requirements. Am I wrong?

- Appendix A:
Unfortunately it has been completely messed up by MS Word and all the bullets are indented in the WRONG way. I, Stefano, will provide a correct version of them.
In the new version I will also update the TPA/TPP with the new CPA/CPP acronyms.