So you say you want a revolution

[Bernd G. Wenzel]

Martin,

you've ignoring an important piece of the puzzle.

Your entity APPROVAL below is syntactically incorrect. Only
ABSTRACT entities are allowed to have generic types for
attributes. This way we can factor out the commonalities while
being specific on the instanciable level.

IMHO, this is the best compromise between the traditional
specificity of STEP and the genericity of other approaches. When
it comes to instances and implementation, we know what we're
dealing with. On the other side we give implementors the
opportunity to benefit from structural equivalences where they
wish to.

Does this help?

:-) Bernd

---------------------------------
Bernd G. Wenzel
Ganghoferstraße 7b
D-83043 Bad Aibling
Germany

Phone: +49-8061-37232
Fax:      +49-8061-92018
Mobile: +49-170-9983565
Email:   bg_wenzel at csi.com

----- Original Message -----
From: "Martin Hardwick" <hardwick at steptools.com>
To: <edbark at nist.gov>; <wg11 at steptools.com>
Sent: Thursday, October 25, 2001 5:15 PM
Subject: So you say you want a revolution


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