So you say you want a revolution

[Martin Hardwick]

At 04:50 PM 10/24/2001 -0400, Ed Barkmeyer wrote:
>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.

Ed,

I think the new types may have revolutionary consequences at a level
above the 20 series specifications. For the specifications themselves
I am sure we can fight through the issues.

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;

I think this is revolutionary for STEP because we have always required
the information modeler and the information writer to be very precise
about what they are writing on the assumption that this will make the
job of the information reader easier. 

This is what people mean when they talk about the goal of STEP being to
produce a CUPM or Complete Unambiguous Product Model.

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. While we
may be able to quickly make the SDAI for example complete in the sense that
it can read the data types, it may no longer be complete in the sense
that it supports the kinds of data navigation and discovery required
to successfully read and interpret the data.

Martin