So you say you want a revolution

[Phil Spiby]

Ed,

You are almost, but not quite right (according to the DAM) with regard to
the need for the ABSTRACT keyword. The DAM states that only abstract
entities may have non-concrete attribute specifications, an abstract entity
is an entity which contains the just the keyword ABSTRACT, so the example
should be:

ENTITY approval ABSTRACT;
  something_that_is_the_approver  : GENERIC;
  somethingelse_that_is_approved  : GENERIC;
END_ENTITY;

The traditional abstract supertype mechanism is still available in the DAM,
but deprecated inside the entity, the subtype constraint mechanism is
recommended.

The reason for the differences is that abstract supertype is a constraint,
which in the DAM can now also be applied in interfacing schemas, and an
abstract entity is the addition of a capability (bit vague I know, but it
was strongly suggested that we separated these two capabilities!)

With respect to the revolution etc, I agree with Bernd and Ed in that what
we have here is a compromise between the rigid structures liked by tool
vendors, and the flexibility required by the modellers when developing AM's.

Phil

> -----Original Message-----
> From: owner-wg11 at steptools.com [mailto:owner-wg11 at steptools.com]On
> Behalf Of Ed Barkmeyer
> Sent: Thursday, October 25, 2001 10:05 PM
> To: Martin Hardwick
> Cc: edbark at nist.gov; wg11 at steptools.com
> Subject: Re: So you say you want a revolution
>
>
> 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."
>