Part 21 support for GENERIC data type

[Ed Barkmeyer]

Martin Hardwick wrote:

> I took a look at the slides
> and noticed that there is no mention in them of the new
> GENERIC, GENERIC_ENTITY and AGGREGATE data types. These new types
> have more affect on the way P21 files are implemented and could
> be quite revolutionary in their consequences.

Martin is right that type GENERIC presents a problem.  I'm not sure that it is revolutionary.

The problem is as follows:

1. Express v2 permits an ABSTRACT supertype to have attributes of generic types, as long as every instantiable subtype
redeclares them to specific data types.  The generic types are: 
- GENERIC, 
- GENERIC_ENTITY (the supertype of all entity data types), 
- AGGREGATE OF T for any type T, and 
- SET/LIST/BAG/ARRAY of any of the above.

2. Part 21 requires a redeclared attribute to be instantiated in the slot corresponding to the supertype attribute in the entity
instance.  For an entity instance with "internal mapping", the instance instantiates a unique "leaf" subtype and the true
(re-declared) data type of the "generic" attribute should be predictable.

3. For an entity instance that requires "external mapping", the redeclared data type of the generic attribute depends on exactly
which subtypes are instantiated, while the ordering of the partial entity instances depends on the sort order of the entity
names.  This means that the postprocessor can encounter the partial entity instance corresponding to the ABSTRACT supertype
*before* it encounters the partial entity instance(s) that determine(s) the specific datatype of the generic attribute.

4.  There is no real problem with GENERIC_ENTITY, since the form of the value is always an entity instance name (#nnn).  And
there is no real problem with AGGREGATE OF T, where T is a specific datatype, since the external form of a SET, LIST, BAG or
ARRAY of T is the same.  (The internal form can be LIST OF T until the post-processor knows what the whole entity instance
represents.)

5.  The problem is GENERIC and SET/LIST/BAG/ARRAY/AGGREGATE of GENERIC.  For those attribute types, the set of all possible
representations has no compatible forms and may be quite complex, e.g. LIST OF SELECT(aggregates of GENERIC).  It is possible to
determine from the exchange schema what all the redeclarations are and thus what all the possible instantiable forms are, and
the result of that analysis is a kind of pseudo-SELECT data type over that list.  But unlike SELECT types, the current Part 21
encoding rules would not require most of them to use the TYPENAME(VALUE) form -- the postprocessor encounters the VALUE with no
hint as to the expected data type.  

6.  We can't just modify Part 21 to require the TYPENAME(VALUE) syntax for redeclared attributes.  The types constituting the
set of all redeclarations of a generic attribute are not necessarily *named* datatypes, and therefore the TYPENAME does not
exist in general, and the equivalent EXPRESS datatype designator syntax could be quite complex.  (The postprocessor should not
be required to parse arbitrary EXPRESS data type syntax at runtime, nor should the preprocessor be expected to generate it.)

7.  I would suggest that the solution is to require for redeclared attributes a syntax like:
 SUBTYPE:VALUE
where SUBTYPE is the identifier for "the" subtype that redeclares the attribute to the specific data type represented in the
encoded value.
Notes:
- The "specific data type represented in the encoded value" is "specific" only to the extent that Part 21 distinguishes, i.e.
independent of domain restrictions and cardinality requirements.
- Because that value could involve select types, I don't think the redeclared syntax can be SUBTYPE(VALUE) -- the value
representation itself could have that form.  
- In an external mapping (and even an internal mapping), more than one re-declaration of the supertype attribute is possible, as
long as they are compatible, and therefore "the" subtype might actually be any of several subtypes that redeclare the attribute
and are instantiated in the entity instance.  I believe that compatibility would require all of the redeclarations to result in
the same Part 21 representation data type, except for the INTEGER->REAL embedding.
- This notation would not be required for an internal mapping, because the name of the entity instance implies the specific data
type.
- This notation would never be required for a redeclared attribute that does not have a generic data type in its original
declaration, thus affording upward compatibility.

Because of 7, I think the problem is tractable and not "revolutionary".  But it does mean we have to change Part 21.

For Part 28:
- the OSEB does not have this problem, because the name of the entity instance element contains *all* the instantiated "leaf"
subtypes and thus implies a specific data type representation for the attribute.
- the ETEB *does* have this problem because the supertype element contains the supertype attributes *followed by* the partial
entity instances for the subtypes, although technically these can be extracted by suitable calls to your XML parser.
- the LB *may or may not* have this problem, depending on which entity_instance structure is used.  However, it appears that
entity instances requiring external mapping in Part 21 will always have exactly this difficulty in the LB.

-Ed

P.S. I may well have missed some serious drawback to the "solution" I offer, and I will readily accept correction from
experienced STEP tool developers.  

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