Rawlins Comments on CC 1.01 Submission

[Mike Rawlins <rawlins@metronet.com>]

Mike Rawlins comments on CC Submissions 1.0.1
rawlins@metronet.com

A few words in preface:  These comments don't cover the complete range
of documents in your submission.  They instead focus in detail on a few
areas that are covered by a subset of your documents.  These topic areas
are in some cases addressed in more than one document.  In such cases
the comment will be against all relevant documents rather than against
each document individually.

My main concern is that while I strongly support the CC work, there are
a few extremely critical technical deficiencies in the current documents
that I feel are show stoppers.    If they are not adequately addressed I
must vote against approving the documents.  I am willing to work with
whatever CC group(s) are responsible to help correct these deficiencies.



--------------------------------------------
Line Range:

The role of context in the re-usability of Core Components and Business
Processes - ALL
CC Dictionary Entry Naming Conventions - ALL
Methodology for the Discovery and Analysis of Core Components - Section
8.5 lines 251 - 273

Comment Type:
Technical and editorial

Rationale for the comment:
It is hard to get a clear, consistent understanding of the precise
definition and characteristics of a core component by reading these
documents (and referenced sections) independently.

Suggestion for change:
Merge referenced documents and sections into a single document that
defines core components completely in all of its aspects.   This
includes the basic definitions of terms (including context), naming
conventions, and how the concepts are used (including how context is
applied).   This document would precisely specific *what* CCs are as
opposed to the methodology document which says *how* to discover and
analyze them.

Specific syntax dependent instantiations of relevant concepts should be
provided for selected cases to make clear the intention of the
specification authors.

--------------------------------------------
Line Range:
The role of context in the re-usability of Core Components and Business
Processes - 209-219 - Section 5.2.1
CC Dictionary Entry Naming Conventions - 132-134, 196 Section 6 table

Comment Type:
Technical

Rationale for the comment:
Representation types and their relationships to syntax dependent data
types are unclear and insufficiently defined.   Without this fundamental
concept defined, numerous problems and inconsistencies arise in the
actual definition of core components.

To illustrate: The example initial catalog of core components contains
several aggregate entities such as code.details, text.details, and
identification.details which are not even entities, much less
aggregates, but representation types.   We have basic information
entities such as "text" which violate the naming conventions since they
have no representation type - this is because they *are* a
representation type and not an information entity.

The lack of a clear definition of purpose of representation type leads
to unclear distinctions between representation types and reasons for
which to use when.  For example:  Two or more of "Amount", "Measure",
and "Quantity" may seem to apply to entities such as degrees Celsius or
cases of oranges.   The reason for this confusion seems to me that these
types also have *semantic* intent in them and don't just specify the
data types.  "Amount" and "Quantity" seem to be different only because
one applies to monetary units and the other doesn't, but this is a
*semantic* difference and not a difference in datatype or
"representation" as representation is usually defined.   One may argue
that "Amount" and "Quantity" may be different because they reference
different code lists to qualify the expressed value, but again this is a
*semantic* difference and not a *datatype* difference.

Representation types in other uses seem only to deal with data types,
and not semantics.  Without the clear statement that representation
types don't deal with semantics, we have seemingly overlapping types.

Suggestions for changes:
Several changes are required.

A complete, concise definition of "Representation Type" and its purpose
is required.  I assume that the purpose is to provide a level of
abstraction for datatypes and separate the analyst from syntax dependent
datatypes, but this is not explicitly stated.

The representation types in the table must be completed defined with all
relevant attributes.  This exercise may help in removing the cases where
semantics are inherent in the current types, since types with a large
set of common attributes may be shown to be different only in intended
semantic usage (Amount vs. Quantity) for example.     In addition, the
existing set of types may not be sufficient, and we may need to create
new types.  The types must provide example mappings to syntax dependent
datatypes and construct mappings such as UML, XML, and X12 EDI (X12.5)
and EDIFACT (ISO 9735).

It is *critical* that "representation type" be fully defined and the
types specified in version 1.0 of the CC specs.  This is a *fundamental*
issue without which all of the other CC work is only marginally usable.
If it can't be resolved adequately by creating original concepts, then
we should adopt wholesale some already defined set of datatypes, such as
those offered by UML or XML schema, and move forward.

--------------------------------------------
Line Range:
CC Dictionary Entry Naming Conventions - 121 - 130

Comment Type:
Editorial, somewhat technical

Rationale for the comment:
Precise definitions and purpose of "Object Class" and "Property" Term
are only stated in context of Rules.

Suggestion for change:
Precisely define these terms and the purpose of the concept in a
separate section defining basic concepts (along with "Representation
Types" and "Context", etc.).

--------------------------------------------
Line Range:
Methodology for the Discovery and Analysis of Core Components  - Lines
274 - 280


Comment Type:
Editorial/Technical

Rationale for the comment:
This is specification information relating to the definition of a
"functional set".  As such it is a descriptive section belonging in a
document that describes what core components are, and not in a
methodology document about how to discover and analyze core components.

Suggestion for change:
Move this section to the new, unified document describing core
components.

--------------------------------------------
Line Range:
Methodology for the Discovery and Analysis of Core Components 257-262

Comment Type:
Technical

Rationale for the comment:
There should be considerations other than "maximum reuse" in the
creation of aggregates.   I suggest that we should balance this against
efficiency.   For example, maximum reuse may lead to extreme cases where
several levels of aggregates must be included in an aggregate so that a
basic entity in one of them may be used.  This can lead to overly
verbose, cumbersome, and inefficient (for both space and time) XML
syntax representations.

 We must have provisions for accomplishing some degree of what in RDBMS
design is referred to as "denormalizing" for efficiency.  In essence, we
need some guidance as to the appropriate levels of hierarchy granularity
to define.

Suggestion for change:

Add efficiency and economy of representation to balance reusability as
design criteria.

--------------------------------------------
Line Range:

The role of context in the re-usability of Core Components and Business
Processes - ALL
CC Dictionary Entry Naming Conventions - ALL

Comment Type:
Technical

Rationale for the comment:
Insufficient detail as to the precise definition and purpose of an
aggregate.  Is it to contain a base set of properties that all (or
almost all) context instantiations will have in common, or is it the
full set of all all items that may appear in any context
instantiation?   From the example catalogue:  Why do party.details have
a nationality?  This might not apply to a multi-national corporation.
Likewise, party.identification.details has a gender that would not apply
to organizations.

Suggested Change:

Provide more complete definition that would provide a basis for deciding
when and when not to include an item in an aggregate.  I suggest the
restricted, base set approach rather than the all-inclusive "kitchen
sink" approach (additive for a context rather than subtractive - This is
in line with most OO analysis approaches).

--------------------------------------------
Line Range:

The role of context in the re-usability of Core Components and Business
Processes - ALL
CC Dictionary Entry Naming Conventions - ALL

Comment Type:
Technical

Rationale for the comment:
Initial catalog has properties such as party type whose purpose seems to
imply using a "type code" to identify the type of party such as
"Seller".  This is an EDI syntax dependent feature that has no place in
definition of core components.

Suggested Change:

Need to clearly define core components as being, in OO terms, abstract.
This would clearly prohibit this usage of "type" when developing an
aggregate CC.  Provide example instantiations to show how concrete
entities are derived from abstract aggregates.  For example:

"Party" in various syntaxes to express a "Selling Party":

OO (Java) - Party abstract class and SellingParty descendent concrete
class

XML Schema - "Party" is defined as a complexType with all of the
relevant child elements and attributes.  Element "SellingParty" is
declared as type "Party"

    <xsd:element name="SellingParty" type="Party"/>

EDIFACT - A NAD segment group is used to convey "Party" with NAD01
(element 3035) having a value of "SE" for seller.

--
Michael C. Rawlins, Rawlins EC Consulting
http://www.metronet.com/~rawlins/