EXPRESS DAm -- A request from the Part 108 folk

[Michael Pratt]

EXPRESS experts,

This is an informal follow-up to Ed Barkmeyer's earlier message (below).
The slight delay is because I have been making some small changes to Part
108 following its CD ballot, and wanted to comply with the latest version.
Ed's analysis of our situation is essentially correct, and all I am doing at
this stage is providing some details of how we are actually modelling
instance attribute references in Part 108 at present, and seeking
suggestions as to what might possibly be included in EXPRESS-2 to allow us
to achieve what we need in a more formal and elegant manner.  The details
mentioned above are in the attached textfile.

Regarding Bernd Wenzel's comments, the Parametrics team had long ago
requested additional capabilities in EXPRESS-2 (now -3) to meet our
requirements (see the second attached file).  However, we developed
alternative, less satisfactory, methods of achieving what we need, primarily
on the recommendation of Bernd himself, who advised us not to rely on those
capabilities ever becoming part of the standard.  For this reason we were
not shattered when EXPRESS-3 was cancelled, but if there is a possibility of
importing some of its capabilities that are relevant to us into EXPRESS-2 we
would be very pleased and better able to get on with our work.

Best regards,

Mike

Dr Michael J. Pratt, leader, WG12 Parametrics Team
LMR Systems
21 High Street
Carlton, Bedford
MK43 7LA
UNITED KINGDOM

Tel/Fax: +44 (0)1234 721720
E-mail: mike at lmr.clara.co.uk

----- 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 6: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."
>
>
-------------- next part --------------
One of the crucial intended capabilities of Part 108 is the ability to associate a parameter (the Part 108 entity is bound_model_parameter) with a specified attribute of a specified instance in a populated EXPRESS schema.  This could be a dimensional attribute, e.g. the radius attribute of a circle instance in a shape model.

The current method of referencing the attribute concerned has changed a bit as the result of CD ballot comments, and now makes use of the following entity:

ENTITY instance_attribute_reference
  SUBTYPE OF (variable_semantics); 	 -- a PLIB Part 20 entity
  attribute_name : attribute_identifier; -- a specialized STRING 
  owning_instance : representation_item;
END_ENTITY;

This allows us to reference the specified instance directly, though we might prefer its type to be generic rather than rep_item.  However, we have no option other than using a STRING to specify the attribute of interest (the string is in fact restricted so that it does not contain anything inappropriate for a qualified EXPRESS identifier).

Problems are that 

1) attribute_identifier is not a standard EXPRESS dumb string.  It is an 'intelligent string', needing a further level of processing by a postprocessor to extract its meaning and set up the required association in the receiving system.  This may well be OK, but it would be nice to have some sanction for referencing instance attributes by the provision of an 'official' capability in EXPRESS-2.  As I said above, the ability to reference these attributes is a vital necessity in Part 108. 

2) The more major problem is that we want to be able to extract the value of the instance attribute concerned, and to use it as the value of a DERIVEd attribute of model_parameter.  At present we are forced back on specifying the value of the model_parameter as indeterminate in an exchange file and writing an informal proposition to say that it shall be the same as the referenced attribute value following the transfer.

Anything that can be provided in EXPRESS-2 to enable us to improve this rather clumsy mechanism will be much appreciated.

The following is a slightly simplified  example of how the parameter association currently appears in a Part 21 file.  The parameter is attached to the `x' dimensional attribute of a Part 42 block entity.  The current value of that attribute is 4.0.  The entity instance_attribute_reference was defined earlier.  The domain of validity of the bound_model_parameter is the closed real interval [2.0, 10.0].  The entity parametric_environment is a subtype of a PLIB Part 20 entity used to relate a variable (in this case the bound_model_parameter) to its semantics (in this case the instance attribute).

#290 = AXIS2_PLACEMENT_3D(...);
#300 = BLOCK('BLOCK1', #290, 4.0, 6.0, 8.0);
#310 = INSTANCE_ATTRIBUTE_REFERENCE('GEOMETRIC_MODEL_SCHEMA.BLOCK.X', #300);
#320 = FINITE_REAL_INTERVAL(2.0, CLOSED, 10.0, CLOSED);
#330 = BOUND_MODEL_PARAMETER(#320, ?); 
#340 = PARAMETRIC_ENVIRONMENT(#310, #330);

Note that the value (second attribute) of the bound_model_parameter instance has to be specified as indeterminate because EXPRESS provides no formal way of deriving its value from #300.  We would like to have such a formal mechanism available to us.