Comments for ebXML spec+whitepaper

[Zongwei Luo <zongwei@us.ibm.com>]

Here are  comments for the ebXML specs or whitepapers.

Comment format

[1]  document reference

(0). Overall comments for the document

(1). Line specific comments




[1] EbXML CC Dictionary Entry Naming Conventions Version 1.01

(0)

This document is a mature technical specification. It can be easily
understood.
One concern is how to differentiate a basic information entity from an
aggregate information entity in a special case:

Lines 148-149 mention that the Property Term "Indentification" could be
omitted if Representation Type is "Identifier". Is it possible that
Property term is the same as a Representation Type? If yes, when the
Property Term is omitted, the name could not suggest whether it is a basic
information entity or an aggregate information entity.

Is it necessary for such a differentiation?

(1)

138 partial paraphrase mark
206 "According" should be "According to"

[2].  The Initial Catalog of Core Components Version 1.01

(0)

This document is not very clear (Intention, Functionality and scope).

(1)

64 "As mentioned above", really none is mentioned above
70 ebXML Business Process specification schema version 1.01 could not be
found as a document. Is it a different doc name?
84 document title should be changed to the title in line 112

[3] Core Component and Business Process Document Overview Version 1.01

(0)

The document is not in alignment with other documents.

(1)

67 I. EbXML Business specification schema Ver 0.90 could not be found.
Version number is not in alignment with line 70 in [3].
65 ; shoud be :
77 ; should be :
94 - 95 5.5 is not included in the diagram. The diagram is not self
explanatory.
112-114 Are they future work? ( semantics of economic exchanges and
contracts, multi-party choreography, and context based content.)
117-129 description about the relationship between discovery and analysis
is not clear.
128-129 diagram is not self-explanatory. Al should be All?

[4] ebXML Methodology for the Discovery and Analysis of Core Components
Version 1.01

(0)

There are needs for:
?    Modeling techniques and methodology to derive business processes with
core and context
?    Configurable negotiation
?    Semantically concise solution -- ontology
?    Core vs. Extension ->  inheritance?

Cannot see the value of using natural language in analysis demonstration.
It is very distracting instead. Cannot see why this analysis approach offer
a smaller set of categorization. Instead, it shows the importance of well
defined categorization of core components.

(1)

Table in section 7 is hard to follow.
372  is to not should be is not to
380 No explanation why the sweet-spot approach is better.
425 This is very much dependent on the language sentence. If a different
sentence is used for the same purpose, how do you determine the similarity
of these two sentences and how this similarity will affect the analysis
procedures?
467 should be figure 5
491 Figure 6 is missing

[5] ebXML The role of context in the reusability of Core Components and
Business Processes Version 1.01

(0)

Thoughts:
Context dependent rules are hard to apply. Why don't we allow trading
partners to negotiate the order to apply rules if a general guidelines
could not be agreed upon to be enforced?
Context dependent object inheritance?
Core vs. Extension? If extensions are not reusable, the whole ebXML is in
danger. Core either needs to cover everthing or there is a good pair of
core+extension.

This document illustrate some basic concepts. No application rules are
presented. It should be renamed as "Context classification".

(1)

119-123 No explanations on how these categorizations are obtained. It is
very interesting to ask in general how the discovery and analysis approach
shown in [4] can be applied here. No relationship is shown here with [4].
129-131  Are all these changes made to core? What are the implications?

[6] ebXML specification for the application of XML based assembly and
context rules Version 1.01

(0)

This seems the basis for discovery and analysis of  core component and
business processes. However, no connections are made among them.

Thoughts: how to use these rules to assemble processes? It is not addressed
at all.

175-177 need to show the relationship with discovery and analysis
173-178 repeat what is stated in [5]
[187-214] repeat what is already stated in [5]

[7] Collaboration-Protocol Profile and Agreement Specification Version
0.911

(0)

The business process specification is considered an atomic entity in CPP/A.
CPP/A only specifies the business process specification transport means.
Though a role (collaboration role) is used to associate with each business
process specification, it is assigned to the whole xml. This means a role
is responsible for the entire conversation. Then that how to define role
becomes an important topic.

Throughout the whole spec, very few lines are spent on error handling. Is
there a way to incorporate this into the spec? Error messaging spec is
needed.

(1)

225 Why not referring doc assembling with rules in [6]
275-287 are not connecting with [2]
399-400 who actually defines the dictionary entries for CPP if this is not
the role of this doc? No connection is shown here with [2]


-ZongWei