Re: Abstract Type vs. Type Code

[Martin Bryan <mtbryan@sgml.u-net.com>]

Mike Rawlins wrote

:I don't think keeping a type code
> in a superclass in order to keep a list of the subclass members is
something we
> want to do.  I'm sure that my experience in object modeling is limited
compared
> to several of your members, but I've never seen it.  Has anyone else?
>
> personally don't think keeping a type code

Agreed, but first we need to realise that Type is being overloaded by the
Core Components team.

In the business process model there is something called Role that partners
"play" in transactions. Core Components use Type to indicate role. If they
changed the name of those places where Type is being used to identify the
Role being played the link between core components and business processes
would be much clearer.

The second way in which Type is being used is that of "qualifier". This is
intended to be used to distinguish specific subsets of a subtype which are
not distinguished within the core component definition. All qualifiers are,
in fact, names that should be applied to a set of context rules that apply
to the subset for particular industries/process/etc.

The third way in which type is being misused is to identify changes of
datatype.

In all three cases Type is used to identify a subsetting role that is
affected by the context in which the parent element is being used. This is
the key reason why your statement about dropping type codes is correct. It
is a fundamental part of assembly (which assigns role names) and context
rules (which idnentify qualification and datatype restrictions.

Martin Bryan