EXPRESS DAm -- A request from the Part 108 folk

[Bernd G. Wenzel]

Ed,

I have to admit, that I'm in nasty mode right now, but according
to my understanding, all these requirements have been taken care
of in the context of a language called EXPRESS-3. This project
has been cancelled not too long ago, because the EXPRESS DAM was
considered to contain "all concepts from EXPRESS-3, which are of
real value for SC4". Did we make a mistake?

I see 2 solutions:

Solution 1:
We try to do the simple and obvious thing - as last time - and
steal from EXPRESS-3 just the minimum concepts, for which we see
a requirement right now, to incorporate them into the EXPRESS
DAM.
This will delay the EXPRESS DAM and all work depending on it,
such as the STEP Modularization. In addition, I'm fairly certain,
that we will face the same situation again; Any ideas, which
EXPRESS-3 concept we will identify as necessary before the
extended EXPRESS DAM will be finished?

Solution 2:
We go ahead with the EXPRESS DAM as scoped so far and re-start
and of course re-fund the EXPRESS-3 project. I understand, that
this is going to cause an unacceptable delay for P108, but I
haven't heard them crying when EXPRESS-3 was shot down. I'm sorry
to say so, but they are not going to get, what they didn't ask
for during the process of the EXPRESS-3 cancellation.

I'm sure, that not everyone on the CC list will consider my
comments constructive, but that's not really my problem. The
EXPRESS team has always done a good job anticipating the
modelling requirements for SC4 ahead of time. It is my
understanding, that EXPRESS-3 could be at least on FDIS level by
now, if the efforts and resources invested into the EXPRESS DAM
would have been directed to the EXPRESS-3 project. In particular,
nobody would have been able to argue, that the only reason for
the EXPRESS-3 project was to secure Phil Spiby's travel funding
in this case.

:-) 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: "Ed Barkmeyer" <edbark at nist.gov>
To: "SC4 WG11" <wg11 at steptools.com>
Cc: "Pratt, Mike" <pratt at cme.nist.gov>; "Paul, Greg"
<ISOWG12 at imc7.ems.lmco.com>
Sent: Wednesday, March 06, 2002 7:06 PM
Subject: EXPRESS DAm -- A request from the Part 108 folk


>
> EXPRESS experts:
>
> At the Myrtle Beach meeting, I was contacted by Mike Pratt of
the Part 108
> team.  There is a modeling concept that they can only weakly
document in
> Express, so weakly in fact that the most important WHERE rules
in the Part 108
> model can only be written as "informal propositions".  (I have
been told by
> several WG3 persons, however, that this is a typical
state-of-affairs and we
> should not be overly concerned. ;-)  Mike has promised to send
WG11 an excerpt
> from the Part 108 schema and text that illustrates the problem.
(I told Mike
> that we cannot officially go beyond the NB comments in editing
the DAm unless we
> get a formal request from the Part 108 team.)
>
> The issues are two:
>
> 1. reference to an Express-defined attribute of an entity
instance IN THE DATA
> (the Part 21/28 file);
>
> 2. reference to the value of a variable (i.e. dynamically
chosen)
> Express-defined attribute IN THE SCHEMA.
>
>
> Issue 2 first.
>
> It is my understanding that the Part 108 excerpt would look
something like:
>
> (* attribute_identifier is a string value that identifies a
modeled Express
>    attribute, in the form:  <schema>.<entity>.<attribute>
>  *)
> TYPE attribute_identifier = STRING; END_TYPE;
>
> ENTITY referenced_element;
>   ref_object: representation_item;
>   ref_role:   attribute_identifier;
> DERIVE
>   ref_value: NUMBER := ???ValueOf???(ref_object, ref_role)
> END_ENTITY;
>
> ENTITY parameter;
>   model_reference:  referenced_element;
>   parameter_value:  NUMBER;
> WHERE
>   parameter_value_must_match_referenced_attribute:
>     parameter_value = referenced_element.ref_value;
> END_ENTITY;
>
> For the Express DAm, can we define the function denoted by
???ValueOf??? in the
> above?  That is, can we define a function that is equivalent to
the attribute
> selection operation (.) when the second operand is a constant,
but allows the
> attribute-name (role name) to be variable?
>
> Note: The ref_object would probably have to be "narrowed" to
the particular
> subtype of representation_item implied by the "completely
qualified role name".
> That can be defined to be the behavior of the ???ValueOf???
operation.  But it
> implies that we might also need a function for the group
selection operation (\)
> as well, e.g.:
>  FUNCTION GroupOf(inst: GENERIC_ENTITY:et, gtype: STRING):
GENERIC_ENTITY:gt;
> which returns inst as a value of type gtype, where gtype/gt is
a subtype of et.
> Of course, this would force us to define the data type of the
value returned by
> the group operator, which is not in fact the gtype entity type,
but rather a
> data set comprising the values of the attributes declared in
the declaration of
> gtype (and no others)!  A partial entity instance is a
record/struct object that
> doesn't have an Express data type!  (This, and value
comparison, are the places
> in which it is necessary to make a distinction between the
entity instance and a
> record/struct of (some of) its attribute values.  The designers
of Express
> decided there were no such places and discarded the vocabulary
needed to define
> these operations.)
>
> Also relative to the above and Jochen's SEDS, should we think
about importing
> into the DAm the Express Ed3 concept of typenames and rolenames
as first-class
> datatypes different from STRING?  Then we could avoid creating
the ValueOf and
> GroupOf functions and just use .(<expression>) and
\(<expression>), where the
> values of the <expression>s are of type rolename and typename
respectively.  The
> problem with this idea is that it might invalidate existing
schemas that use
> string-literals, and more rarely but less remediably STRING
variables, to denote
> values of these types.
>
> Now Issue 1.
>
> To the best of my knowledge, values of the typename and
rolename types do not
> appear in existing STEP or PLIB data sets.  They only appear in
schemas.  But
> they will appear in future data sets conforming to Part 108!
If we formalize
> the typename and rolename types in Express, then we will have
to change Part 21
> to write the rule for their representation.  But if we don't
formalize them in
> Express, we will have no peg on which to hang that rule in Part
21.  And if WG11
> does not act on this, the syntax for the representation of
Express role names in
> Part 21 files will be defined in Part 108!
>
> -Ed
>
> P.S. This is by way of early warning.  We may not see an
official request from
> WG12 (for Part 108) until just before the Stockholm meeting.
>
> --
> 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."