This page gives you a short and simplified introduction to EXPRESS, the information modeling language used throughout STEP and other international standards. The only one reference document for EXPRESS is ISO 10303-11. You can buy it either at your national standard representative or at ISO.

Currently there are two versions of EXPRESS. Version 1 got released and published in 1994 and there are two technical corrigenda available for this. Version 2 got finalized in 2003 and is expected to be published in late 2003 or early 2004 by ISO. EXPRESS is developed and maintained by ISO TC184/SC4-WG11.


An EXPRESS data model can be defined in two ways, in ASCII and graphically. For formal verification and as input for tools such as JSDAI, the ASCII representation is the most important one. The graphical representation on the other hand is often more suitable for human use, such as explanation and tutorials. The graphical representation, called EXPRESS-G, is not able to represent all details, which can be formulated in the textual form.

EXPRESS is similar to programming languages such as PASCAL. Within a SCHEMA various datatypes can be defined together with structural constraints and algorithmic rules. A main feature of EXPRESS is the possibility to formally validate a population of datatypes - this is to check for all the structural and algorithmic rules.


Below the various datatypes of EXPRESS are listed. A value of a specific datatype may always have an unset value. In the EXPRESS language this is indicated by a "?" and in a STEP-File with "$". JSDAI throws exceptions when trying to read an entity attribute of an unset value.

  • simple_type
    • string_type: This is the most used simple type. EXPRESS strings can be of any length and can contain any character (ISO 10646/Unicode).
    • integer_type: EXPRESS integers in principle can have any length, but all implementations such as JSDAI restrict them to a 32 bit value with sign.
    • real_type: Ideally an EXPRESS real value is unlimited in accuracy and size. But in practice a real value is represented by a floating point value of type double.
    • number_type: The number data type is a supertype of both, integer and real. In JSDAI it is always handled as real, even if it is an integer.
    • boolean_type: With the boolean values TRUE and FALSE it is clear that this maps to the Java boolean. But do not forget that even a boolean value may be unset.
    • logical_type: Similar to boolean, the logical datatype has the possible values TRUE and FALSE and in addition UNKNOWN. Together with unset these are 4 possible values.
    • binary_type: This data type is rarely used. It covers a number of bits (not bytes). For some implementations the size is limited to 32 bit. In JSDAI its size is not limited, but this data type is clearly not suitable for storing bigger binary values such as a a bitmap or similar. EXPRESS clearly lacks a datatype on byte boundary, being able to handle big datasets. Some STEP-APs defined entities to represent external data files (e.g. digital_file in AP214) for unlimited big files. JSDAI has special support for these by being able to check in/out files for any entity instance.
  • defined_type. They can be used to specialize other datatypes further on. E.g. it is possible to define the datatype positive which is of type integer with a value > 0.
  • entity_type: This is the most important datatype in express. It is covered below more detail. Entity data types can be related in two ways, in a sub-supertype tree and by attributes.
  • enumeration_type: Enumeration values are simple strings such as red, green, and blue for an rgb-enumeration. Starting with EXPRESS ed2, enumerations can be extended in other schemas.
  • select_type: Select defines a choice or an alternative between different options. Most commonly used are selects between different entity_types. More rarely are selects, which include defined types. Starting with EXPRESS ed2, select data types can be extended in other schemas.
  • aggregation_type: The possible kinds of agregation_types are SET, BAG, LIST and ARRAY. While SET and BAG are unordered, LIST and ARRAY are ordered. A BAG may contain a particular value more than once, this is not allowed for SET. An ARRAY is the only aggregate which may contain unset members. This is not possible for SET, LIST, BAG. The members of an aggregate may be of any other data type.

Several general things must to be mentioned for datatypes.

  • Constructed datatypes can be defined within an EXPRESS schema. They are mainly used to define entities, and to specify the type of entity attributes and aggregate members.
  • Datatypes can be used in a recursive way to build up more and more complex data types. E.g. it is possible to define a LIST of an ARRAY of a SELECT of either some entities or other datatypes. If it makes sense to define such datatypes is a different question.
  • EXPRESS defines a couple of rules how a datatype can be further specialized. This is important for redeclared attributes of entities.
  • Within procedures and functions it is possible to use GENERIC datatypes. With EXPRESS ed2 this is also to some degree allowed for abstract entities.
  • For every data type we can have values. The JSDAI class Value can represent any datatype. As explained before, the value may be unset. For most entities and complex collections of entities it is possible to create an instance. This is a named value (e.g. the #-number in a STEP-File).

Sub- and supertypes

An entity can be defined to be a subtype of one or several other entities (multiple inheritance is allowed!). A supertype can have any number of subtypes. It is very common practice in STEP to build very complex sub-supertype graphs. Some graphs relate 100 and more entities with each other.

An entity instance can be constructed for either a single entity (if not abstract) or for a complex combination of entities in such a sub-supertype graph. For the big graphs the number of possible combinations is likely to grow in astronomic ranges. To restrict the possible combinations special supertype constraints were introduced such as ONEOF and TOTALOVER. Furthermore, an entity can be declared to be abstract to enforce that no instance can be constructed of just this entity but only if it contains a non-abstract subtype.


Entity attributes allow adding "properties" to entities and relating one entity with another one in a specific role. The name of the attribute specifies the role. Most datatypes can directly serve as type of an attribute. This includes aggregation as well.

There are three different kinds of attributes, explicit, derived and inverse attributes. And all these can be redeclared in a subtype. In addition, an explicit attribute can be redeclared as derived in a subtype. No other change of the kind of attributes is possible.

  • Explicit attributes are those which have direct values visible in a STEP-File.
  • Derived attributes get their values from an expression. In most cases the expression refers to other attributes of THIS instance. The expression may also use EXPRESS functions.
  • Inverse attributes do not add "information" to an entity, but only name and constrain an explicit attribute to an entity from the other end.

Algorithmic constraints

Entities and defined data types may be further constraint with WHERE rules. WHERE rules are also part of global rules. A WHERE rule is an expression, which must evaluate to TRUE, otherwise a population of an EXPRESS schema is not valid. Like derived attributes these expression may invoke EXPRESS functions, which may further invoke EXPRESS procedures. The functions and procedures allow formulating complex statements with local variables, parameters and constants - very similar to a programming language.