An Express schema can take advantage of elements defined in other Express schemas by the USE FROM and REFERENCE FROM keywords. A long form schema is an Express schema, which is fully self-contained without any USE FROM or REFERENCE FROM section. A short form schema on the other hand uses these keywords to use or references other schemas completely or elements thereof.
By default the master of all AIM schemas in STEP are given in short form. For STEP-APs one or several long form schemas are derived from the short form schema in addition. This is done because in the early days of STEP and still today a couple of STEP toolkits cannot operate on short form schemas.
For JSDAI you can choose whether to use long or short from. Both are supported. Since the short form has several advantages they are included in the JSDAI-Library only.
Unfortunately these terms are confusing.
To explain it let us assume a data model with the supertype entity A and two subtype entities B and C in an ANDOR combination. A forth entity D is a subtype of both B and C (multiple inheritance). It is then possible to have instances of A, A&B, A&C, A&B&C, and A&B&C&D.
When used outside the official STEP standard documents this means an entity where several subtypes (leaves) are used simultaneously. So the combination of A&B&C is a complex entity while A, A&B, A&C and A&B&C&D are considered as non-complex.
In the official wording of the standard a complex entity data type is the combination of more than one entity. So all the combinations A&B, A&C, A&B&C, and A&B&C&D are considered as complex. To indicate the special situation for A&B&C the 2nd edition of Express introduces the term multi-leaf complex entity (data type).
Note that the representation of entity instances in a STEP-File (part p21) depends on how many leaf entity data types are in a complex entity. If it is only one then the so-called internal mapping is used (at least in conformance class 1 which is in practice used always). If there are two or more leaf entity data types the external mapping has to be used (which is the default for conformance class 2).
So some instance of our data-model would look in a p21 file like this:
The
normative document of EXPRESS with the full specification is ISO
10303-11:2003 (2nd edition). This document is not a tutorial and so we
recommend reading this document only if you already have a solid
understanding of EXPRESS and want to know things in full detail.
You will find a very basic introduction to EXPRESS in the JSDAI documentation. A detailed introduction is given in the book
"Information Modeling: The Express Way" by Douglas A. Schenck, Peter R. Wilson, Peter Mere Latham.
Express defines several kinds of data-types:
For every data type we can have values. Let us use part21 to give a few examples:
An instance is a "named value". Within Express we have only entity instance - or more precisely single entity instances and complex entity instance. Examples of a few instances:
The names of these instances are #10, #20, and #30. The instances #10 and #20 have the same value "A(4)" while instance #30 has the value "A(6)".
Express defined data are instances and values of data-types defined in some Express schema. In principle there are four official ways to store or write such values - only the first two have any practical relevance.
JSDAI fully supports part21 and part28 and to some degree EXPRESS constants. EXPRESS-I is not supported.
