Representation Types Alternatives

[Mike Rawlins <rawlins@metronet.com>]

In my comments during the first review cycle I noted several problems
with representation types as they are currently defined.  I see these
problems as show stoppers that must be fixed before final approval.  The
1.02 documents seem to have few changes in this area.   I suggest that
the two most promising ways to handle my concerns are:

1)  Formally define representation types, refining the current
definitions

2)  Adopt an existing set of data types.  Several candidates exist:  The
most likely is the set identified in the BP Specification Schema,
section 9.1 - Data Typing.  Other choices are the datatypes defined in
XML schema or UML.

Before one or the other is adopted, a pertinent question to ask first is
what is the purpose of representation types?  If the purpose is to:

a)  merely constrain the value space ("set of values" is how it is
stated in the CC spec), then I suggest we take alternative 2 as the
simplest approach.  We may then define a set of primitive properties
such as quantity, amount, etc., that are reusable and may take the place
of some of the current representation types that would be dropped with
such an approach.

b)  If the purpose is to constrain the value space *and* provide the
analyst/modeler with a level of abstraction and higher level of
reusability than the types offered by the Specification Schema, XML, or
UML, then we should define a set of types rather than adopt one.  When
defining the set, we should fully specify all of the relevant fields for
each type (for example - measure has both value and units).

I tend to favor a) since it is simpler, can probably be done with less
effort, and more aligned with the BP and other work.

Regards,

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