EXPRESS Language Syntax

All EXPRESS reserved words are case insensitive. However, for emphasis they are presented in upper case throughout this section.

Keywords

The following is a list of the EXPRESS language keywords.

Operators

Built-in constants

Built-in functions

Built-in procedures

Data Types

EXPRESS data types are classified under the following classes:

• Simple data types.

• Aggregate data types.

• Named data types.

• Constructed data types.

• Generalized data types.

EXPRESS supports the following simple data types:

Jotnes Express compiler accepts some additional data type when the EDM_EXPRESS_EXTENSION option is switched on.

EXPRESS supports the following aggregate data types:

EXPRESS supports two classes of named data types:

There are two classes of constructed data types: ENUMERATION data type and SELECT data type.

There are two main classes of generalized data types: AGGREGATE data type and GENERIC data type.

Entities

EXPRESS is used to define entities. Within the entity definition, all the attributes and behaviors which characterize it are declared. An entity is declared by the keyword ENTITY and terminated by the keyword END_ENTITY.

 ENTITY OwnerID;
……
 END_ENTITY;

Attributes are the characteristics (data or behavior) which are required to support use and understanding of the entity. Attributes may be represented by simple data types (such as real, string, integer), or by other entities. Each attribute has a relationship with the entity. An attribute represented by a simple data type can be shown in EXPRESS by its data type.

ENTITY OwnerID;
	Identifier : String;
	OwningApp : String;
	OwningUser : Actor;
END_ENTITY;

Attributes

An attribute represented by a relationship to another entity is shown by the name of the relationship and the name of the entity with which the relationship exists (in the direction of the relationship). Thus for an LayeredElement with a MtrlLayerSet which is declared as an entity in its own right, EXPRESS takes the form:

ENTITY LayeredElement;
…	MtrlLayerSet : MaterialLayerSet;
…END_ENTITY;

Cardinality

EXPRESS allows numerical relations to be mandatory or optional. A mandatory attribute which must be asserted is expressed by there being no prefix term before the attribute name as in the example above. An optional attribute that may be asserted is expressed by the word OPTIONAL appearing as a prefix term before the attribute name

ENTITY LayeredElement;
…	TotalAreaPerSide : OPTIONAL AreaMeasure;
	TotalVolume : OPTIONAL VolumeMeasure;
	TotalLength : OPTIONAL LengthMeasure;
…END_ENTITY;

Inverse Rule

Attributes explicitly capture a relation between entities and attributes Inverse relations can also be captured between an entity and a named attribute of another entity or between two entities.

ENTITY ProjectObject
…	ResultOf : SET [0:?] OF ProcessObject;
…	UNIQUE
		UR1: OwnerID;
END_ENTITY;


ENTITY ProcessObject;
…	INVERSE
		ResultsIn : SET[0:?] OF ProjectObject FOR ResultOf;
END_ENTITY;

Note the use of the INVERSE keyword to define the inverse relation

Unique Rule

EXPRESS allows for the uniqueness of attributes to be defined by a 'unique rule'. This specifies that the value of an attribute which is declared to be UNIQUE is associated with only one instance of that entity (object). Where more than one attribute is described as unique, each must be included in the UNIQUE declaration.

ENTITY ProjectObject
… UNIQUE
  UR1: OwnerID;
END_ENTITY;

Derive Rule

In some cases, it is appropriate to include an attribute, which can be computed directly from other attributes. This can be achieved through use of derived attributes which are declared following the DERIVE keyword. The following example also introduces the use of function TotalWidth to calculate the derived value:

ENTITY LayeredElement
… DERIVE
   ImplGeoTotalWidth : LengthMeasure := TotalWidth
   (SELF.MaterialLayerSet);
END_ENTITY;

Where Rule

Where rules (domain rules) is used to provide constraints on the values which attributes may have and is defined following the WHERE keyword. In the example below, the entity can only exist if all three lists have the same number of members. This is used to ensure that those lists actually correspond, i.e. that for each thickness also an offset and a material are given.

ENTITY MaterialLayerSet;
	SetName : OPTIONAL String;
	Offsets : LIST [1:?] OF LengthMeasure;
	Thicknesses : LIST [1:?] OF LengthMeasure;
	Materials : LIST [1:?] OF Material;
	WHERE
		WR1 : (HIINDEX(SELF.Offsets) = HIINDEX(SELF.Thicknesses)) AND (HIINDEX(SELF.Thicknesses) = HIINDEX(SELF.Materials));
END_ENTITY;

Arithmetical statements that are available within EXPRESS may be used in conjunction with the domain rule to provide constraints on attribute values. For instance, if the perimeter length of a window were constrained to be less than or equal to 4 meters, the rule would take the form:

ENTITY Window;
	WINDOW_LENGTH : REAL;
	WINDOW_HEIGHT : REAL;
	WHERE
		perimeter : (WINDOW_LENGTH * 2 + WINDOW_HEIGHT * 2) <= 4.0;
END_ENTITY;

Subtypes

EXPRESS allows for the classification of an entity into subtypes. This defines a parent – child relation in which each subclass (referred to as subtype) contains more specific detail than its parent superclass (referred to as supertype).

ENTITY LayeredElement ABSTRACT SUPERTYPE OF (ONEOF(Floor, RoofSlab, Wall));
…
END_ENTITY;


ENTITY Wall SUBTYPE OF (LayeredElement);
…
END_ENTITY;

Note that the supertype declares the Wall as being 'ONEOF'. This indicates that the layered element is exclusively either a Wall or a Floor or a RoofSlab; it cannot be two or more at the same time. Alternative constraints on subtypes exist, most notably the ANDOR constraint that would allow the layered element to be either a Wall or a Floor or a RoofSlab or any combination of the three subtypes at the same time.. EXPRESS supports both, single inheritance and multiple inheritance. Having more than one entity within the SUBTYPE clause specifies multiple inheritance. A supertype may be included for the purposes of classification only, such situations occurring where it may be appropriate to include a supertype within the EXPRESS model for clarity. A supertype included for this purpose is never instanced; only its subtypes are used. In this case, it is known as an abstract supertype. The LayeredElement is an example of an abstract supertype.

Declared Data Types

The type of a data item being used may be declared using a TYPE clause. For certain types of data item, this is necessary whilst for simple data types, it is optional. For instance, consider a space type that may be selected from an enumerated list of occupied, technical or circulation. The enumeration is declared as a data type as below:

TYPE SpaceTypeEnum = ENUMERATION OF (Occupied, Technical, Circulation);
END_TYPE;

Note that the use of the TYPE clause causes the declaration of the attribute within the entity to be written in the same manner as if the relationship was with another entity.

A SELECT data type defines a named collection of other data types. These may be other entities, a list of string values, a list of real values etc. As with enumeration’s, only one item from a SELECT list is used by an instance of the entity, which uses the TYPE.

TYPE BuildingSelect = SELECT (Building, BuildingStorey);
END_TYPE;

Access to Other Schema

Entities that are defined in schema other than that which is current may be accessed using an EXPRESS interface. This allows schema to be partitioned into manageable parts and enables reuse of schema, which may have been previously defined or defined elsewhere. There are two interface possibilities.

The REFERENCE specification allows declarations made in other schema (usually entities) to be referenced but does not make them part of the current schema i.e. the declarations remain remote. The following indicates the referencing of entities defined in a geometry schema.

 REFERENCE FROM GeometryResource (CartesianPoint, Bounded_curve, Polyline, Trimmed_curve, CompositeCurve, Placement, Line, Conic,Circle, Ellipse));