WG11: A GENERIC alternative?

[Ed Barkmeyer]

All,

Martin's complaint on the "so you say you want a revolution"
thread was that it may require the underlying implementation
models in STEP tooling to undergo substantial modification or
even be discarded outright.  
My diatribe of yesterday notwithstanding, Martin has a point
here!

If you actually view a complex entity instance as a collection of
record/struct/class objects representing the partial entity
instances, then you cannot easily produce a programming language
data type that holds the representation of some kinds of generic
attributes.  And if you don't represent those attributes in the
software object corresponding to the supertype entity, there is
no value in having declared them there!  (They can only be
manipulated as attributes of wherever they are redeclared.)  At
best the mapping of the ABSTRACT entity data type depends on what
else appears in that schema.  And if a "module" contains one of
those, and that abstract type might be inherited by some type in
another module, then you cannot implement the "module"
independently of the ultimate exchange schema!

Abstract types with generic attributes pretty much ensure that
implementation of anything other than an exchange schema probably
won't work!  And that may be a "revolution" for some of the folks
who invented this feature in order to support "modules".  In
general, it will *not* be possible to build a software module
that corresponds to a "module" of the STEP standard!

As Lothar points out, there is a real difference between having
attributes of type GENERIC_ENTITY (whose implementation is not
usually difficult, and is *required* for Part 22) and having
attributes of type GENERIC.  It may be better to adopt an SC4
convention that, except in very rare cases, GENERIC attributes be
replaced by attributes whose data type is an empty EXTENSIBLE
SELECT.  That is, instead of:

ENTITY archetype ABSTRACT;
 archetypal_attr: GENERIC;
END_ENTITY;

use:

TYPE archetypal_value = EXTENSIBLE SELECT;
ENTITY archetype ABSTRACT;
 archetypal_attr: archetypal_value;
END_ENTITY;

Then each instantiating schema must declare a SELECT type BASED
ON archetypal_value, giving (some of) the types in the select
list for its use of archetypal_value.  And if appropriate, an
instantiable subtype can also redeclare the archetypal_attr to
one of the types in the select list.  (So the modelers may have
to do a bit more typing, but the same effect as the GENERIC
attribute can be achieved.)

That requirement would eliminate the need for changes to Part 21,
except for whatever the "very rare cases" might be.  It turns an
implicitly discriminated union into an explicitly discriminated
union, where the explicit discriminator is the name of the data
type from the ultimate select list.  (I.e. it turns a selection
from the set of redeclarations into an explicit SELECT type with
named choices.)

Using EXTENSIBLE SELECT also introduces some other useful
capabilities.  The extended select type in the instantiating
module can itself be "open" (EXTENSIBLE), allowing further
selections to be added by schemas that USE that module, or
"closed" so that the inheriting entities in that module do *not*
have other choices!  It can also be divided into subcategories by
having more than one extended select type based on it.  

Of course this approach assumes that it is somehow easier for a
STEP processor to implement a SELECT type that may grow
additional select list choices than to implement a type that has
a wholly undefined set of choices, which isn't much different! 
But an EXTENSIBLE SELECT type is *not* a "generic attribute
type", and implementations will have to support it anyway.  (That
may just be further grist for Martin's revolution mill.  I don't
know.)

Following David Price's line of thought, and an old Paul Simon
ditty, "there must be 50 ways to leave your lover."  This is yet
another approach.  I am not recommending it, but Martin might
want to.  It would not be the first time that SC4 in the large
undid what the Express committee did!

-Ed

-- 
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."