So you say you want a revolution

[Ed Barkmeyer]

Martin Hardwick wrote:

> If I am correct the new Generic entity means some future schema may
> model an approval as follows:
> 
> ENTITY approval;
> something_that_is_the_approver  : GENERIC;
> somethingelse_that_is_approved          : GENERIC;
> END_ENTITY;

Bernd is right.  Between "approval" and the semicolon, you must insert "ABSTRACT SUPERTYPE" in order for the above to be valid
Express.  And having done that, you have defined an entity called "approval" that cannot be used directly in an exchange!

> The new style of modeling implied by the above example is a valid one
> that may or may not be better than the STEP one. Without doubt however
> it is at the opposite end of the modeling spectrum. It is the kind of
> object modeling that has been supported for years by systems such as
> LISP, KIF/KQML and Objective C amongst others.
> 
> In this style the system that is reading the data goes on a voyage of
> discovery. As it moves through the data it discovers more facts (the
> instance at the other end of the GENERIC will be something specific
> and that will allow the reader to either make a decision about what
> it is reading or adopt a more specific theory about what it is going
> to be reading.)
> 
> Therefore, I submit that the proposal is revolutionary for implementors
> because they must support a radically different reading style. 

None of this is true.  The only entity types that can actually appear directly in an exchange are the leaf types of the
inheritance tree, and in those types, every inherited generic attribute must be re-declared to a specific Express:1994 data
type.  So when you look at an instantiable exchange schema, all of those generic attributes disappear!

What this new feature does do is to wreck the last vestiges of "implementing IRMs", as distinct from "implementing AIMs".  The
IRMs do *not* in general, and never did, constitute a "conceptual schema".  Many IRM schemata are meta-models, and the "generic
attribute" feature further enhances the meta-modeling capabilities of Express.  An ABSTRACT SUPERTYPE with a generic attribute
is not a "class"; it is a "pattern" for the subtypes that "inherit" from it.

This may be revolutionary for implementors who believe that the IRMs were a "conceptual schema" and have built interesting
multiple-AIM systems and "AIM-independent tools" around the mix of models and meta-models that SC4 has developed.  But it is not
revolutionary for those who understand that the only schemata that have meaning in STEP are the AIMs.  In general, the semantics
of the union or intersection of two AIMs is *undefined*!  With a moderate amount of self-deception you could convince yourself
that the set of IRM entities in the union of two AIMs was at least semantically define-able in some useful cases.  What the
generic attribute feature does is to allow the creation of IRM entities that are *obviously* undefined!  I don't see that as
revolutionary; I see it as the inevitable evolution of the mythical reference models.  Your results may vary.

-Ed

P.S. I want a revolution, but I would start by defining a meta-model that does not have a one-to-one map into either Express or
UML.  I'm not likely to find many pragmatists flocking to my red banner. So since we have a working kludge, let's just keep
kludging it, until the real revolution buries us. ;-)

-- 
Edward J. Barkmeyer                       Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Mail Stop 8260          Tel: +1 301-975-3528
Gaithersburg, MD 20899-8260               FAX: +1 301-975-4482

"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."