ISO 10303-21:2016(E)
This clause describes how instances of data types defined in the EXPRESS language defined in annex G of ISO 10303-11 are mapped to the exchange structure.
The EXPRESS language includes TYPE and ENTITY declarations, CONSTANT declarations, constraint specifications and algorithm descriptions. Only instances of data types, as defined by EXPRESS data types and TYPE and ENTITY declarations, are mapped to the exchange structure. Other elements of the language are not mapped to the exchange structure.
EXPRESS element | mapped onto: |
---|---|
ARRAY | list |
BAG | list |
BOOLEAN | boolean |
BINARY | binary |
CONSTANT | entity or value instance |
DERIVED ATTRIBUTE | NO INSTANTIATION |
ENTITY | entity instance |
ENTITY AS ATTRIBUTE | instance name |
ENUMERATION | enumeration |
FUNCTION | NO INSTANTIATION |
INTEGER | integer |
INVERSE | NO INSTANTIATION |
LIST | list |
LOGICAL | enumeration |
NUMBER | real |
PROCEDURE | NO INSTANTIATION |
REAL | real |
REMARKS | NO INSTANTIATION |
RULE | NO INSTANTIATION |
SCHEMA | NO INSTANTIATION |
SELECT | See 12.1.8 |
SET | list |
STRING | string |
TYPE | See 12.1.6 |
UNIQUE rule | NO INSTANTIATION |
WHERE RULES | NO INSTANTIATION |
Values of the EXPRESS data type INTEGER shall be mapped to the exchange structure as an integer data type (see 6.4.1), as a constant value name (see 6.4.4.2), or as a value instance name (see 6.4.4.4).
NOTE In this edition of this part of ISO 10303 instance values can be defined in the reference section (see 10), and as EXPRESS constants.
Values of the EXPRESS data type STRING shall be mapped to the exchange structure as a string data type (see 6.4.3), as a constant value name (see 6.4.4.2), or as a value instance name (see 6.4.4.4).
Values of the EXPRESS data type BOOLEAN shall be mapped to the exchange structure as an enumeration data type (see 6.4.5), as a constant value name (see 6.4.4.2), or a value instance name (see 6.4.4.4).
The EXPRESS data type BOOLEAN shall be treated as a predefined enumerated data type with a value encoded by the graphic characters "T" or "F". These values shall correspond to true and false respectively.
Values of the EXPRESS data type LOGICAL shall be mapped to the exchange structure as an enumeration data type (see 6.4.5), as a constant value name (see 6.4.4.2), or a value instance name (see 6.4.4.4).
The EXPRESS data type LOGICAL shall be treated as a predefined enumerated data type with a value encoded by the graphic characters "T", "F" or "U". These values shall correspond to true, false, and unknown respectively.
Values of the EXPRESS data type REAL shall be mapped to the exchange structure as a real data type (see 6.4.2), as a constant value name (see 6.4.4.2), or as a value instance name (see 6.4.4.4).
EXAMPLE Entity definition in EXPRESS:
ENTITY widget; i1: INTEGER; -----------> A i2: INTEGER; -----------> B s1: STRING(3); -----------> C s2: STRING; -----------> D l : LOGICAL; -----------> E b : BOOLEAN; -----------> F r1: REAL(4); -----------> G r2: REAL; -----------> H r3: REAL; -----------> L r4: REAL; -----------> M END_ENTITY;
Sample instance in the data section:
#2 = WIDGET(99, 99999, 'ABC', 'ABCDEFG', .T., .F., 9., 1.2345, @10, @PI); ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | | | | | | A B C D E F G H L M
A: i1 has a value of 99 in this entity instance.
B: i2 has a value of 99999 in this entity instance.
C: s1 has a value of 'ABC' in this entity instance. This value falls within the range (3 characters) specified for this attribute.
D: s2 has a value of 'ABCDEFG' in this entity instance.
E: l has a value of TRUE in this entity instance.
F: b has a value of FALSE in this entity instance.
G: r1 has the value of 9. in this entity instance. The precision specification does not affect the encoding.
H: r2 has a value of 1.2345 in this entity instance.
L: r3 has a value defined in the reference section.
M: r4 has a value defined in the EXPRESS schema.
Values of the EXPRESS data type BINARY shall be mapped to the exchange structure as a binary data type (see 6.4.6), as a constant value name (see 6.4.4.2), or as a value instance name (see 6.4.4.4).
EXAMPLE Entity definition in EXPRESS:
ENTITY picture; bn : BINARY; END_ENTITY;
Sample entity instance in data section:
#4 = PICTURE("1556FB0"); ^ | A
A: bn has an encoding of "1556FB0" in this instance, corresponding with the bit sequence 101 0101 0110 1111 1011 0000.
Values of the EXPRESS data type NUMBER shall be mapped to the exchange structure as a real data type. 6.4.2 describes the composition of a real data type.
Values of the EXPRESS data type LIST shall be mapped to the exchange structure as a list data type. Clause 7 describes the composition of a list data type. If the LIST is empty, the list shall be encoded as a left parenthesis ("(") followed by a right parenthesis (")"). Within the list, each instance of the element type shall be encoded as specified in clause 12 for that EXPRESS data type.
Values of the EXPRESS data type LIST may be defined in the reference section. The value shall be mapped using the value instance name defined for that instance in the reference section. The value of the instance shall be compatible with the EXPRESS type.
Values of the EXPRESS data type LIST may be defined by EXPRESS constants. The value shall be mapped using the value defined for that instance in the EXPRESS schema. The value of the instance shall be compatible with the EXPRESS type.
NOTE If, in a particular entity instance, no value is provided for an OPTIONAL attribute whose data type is a LIST, the attribute is encoded by a dollar sign ("$"), as specified in 12.2.2, and not as an empty list.
EXAMPLE Entity definition in EXPRESS:
ENTITY widget; attribute1: LIST [0 : ?] OF INTEGER; -----------> A attribute2: LIST [1 : ?] OF INTEGER; -----------> B attribute3: OPTIONAL LIST [1 : ?] OF INTEGER; --> C attribute4: REAL; ------------------------------> D attribute5: LIST [1 : ?] OF INTEGER; --> E END_ENTITY;
Sample entity instance in data section:
#4 = WIDGET((), (1,2,@10), $, 2.56, @PI); ^ ^ ^ ^ ^ | | | | | A B C D E
A: attribute1 is an empty list (list with zero elements).
B: attribute2 contains three elements in this instance. One of the instances is defined by instance @10 in the reference section.
C: attribute3 does not have a value in this instance.
D: attribute4 has a value of 2.56 in this instance.
E: attribute5 has a LIST value defined by the EXPRESS constant PI.
Values of the EXPRESS data type ARRAY shall be mapped to the exchange structure as a list data type. Clause 7 describes the composition of a list data type. If an EXPRESS attribute is a multidimensional array the attribute shall be encoded as a list of lists, nested as deeply as there are dimensions. In constructing such lists, the inner-most list, the list containing only instances of the element type, shall correspond to the right-most ARRAY specifier in the EXPRESS statement defining the entity. The ordering of the elements within the encoding shall be that all the elements of the inner-most list are encoded for each element of the next outer list. This order means that the right-most index in each list shall vary first. Within the list, each instance of the element type shall be encoded as specified in clause 12 for that EXPRESS data type. If the array data type has OPTIONAL elements, any element for which no value is provided shall be encoded by a dollar sign ("$").
Values of the EXPRESS data type ARRAY may be defined in the reference section. The value shall be mapped using the value instance name defined for that instance in the reference section. The value of the instance shall be compatible with the EXPRESS type.
Values of the EXPRESS data type ARRAY may be defined by EXPRESS constants. The value shall be mapped using the value defined for that instance in the EXPRESS schema. The value of the instance shall be compatible with the EXPRESS type.
NOTE If, in a particular entity instance, no value is provided for an OPTIONAL attribute whose data type is an ARRAY, the attribute is encoded by a dollar sign ("$"), as specified in 12.2.2, and not as an empty list.
EXAMPLE 1 Entity definition in EXPRESS:
X : ARRAY[1:5] OF ARRAY[100:102] OF INTEGER
This is encoded in the following order:
( (X [1,100], X [1,101], X [1,102] ), (X [2,100], X [2,101], X [2,102] ), (X [3,100], X [3,101], X [3,102] ), (X [4,100], X [4,101], X [4,102] ), (X [5,100], X [5,101], X [5,102] ) )
EXAMPLE 2 Entity definition in EXPRESS:
ENTITY widget; attribute1: ARRAY [-1 : 3] OF INTEGER; ----------------------> A attribute2: ARRAY [1 : 5] OF OPTIONAL INTEGER; --------------> B attribute3: ARRAY [1 : 2] OF ARRAY [1 : 3] OF INTEGER; ------> C END_ENTITY;
Sample entity instance in data section:
#30 = WIDGET((1,2,3,4,5) , (1,2,3,$,5) , ((1,2,3),(4,5,6))); ^ ^ ^ | | | A B C
A: attribute1 contains the following values:
attribute1 [-1] = 1 attribute1 [0] = 2 attribute1 [1] = 3 attribute1 [2] = 4 attribute1 [3] = 5
B: attribute2 contains the following values:
attribute2 [1] = 1 attribute2 [2] = 2 attribute2 [3] = 3 attribute2 [4] = not provided attribute2 [5] = 5
The significance of a missing value is defined within the EXPRESS schema.
C: attribute3 contains the following values:
attribute3 [1,1] = 1 attribute3 [1,2] = 2 attribute3 [1,3] = 3 attribute3 [2,1] = 4 attribute3 [2,2] = 5 attribute3 [2,3] = 6
Values of the EXPRESS data type SET shall be mapped to the exchange structure as a list data type. Clause 7 describes the composition of a list data type. Within the list, each instance of the element type shall be encoded as specified in clause 12 for that EXPRESS data type. If the SET is empty, the list shall be encoded as a left parenthesis ("(") followed by a right parenthesis (")").
Values of the EXPRESS data type SET may be defined in the reference section. The value shall be mapped using the value instance name defined for that instance in the reference section. The value of the instance shall be compatible with the EXPRESS type.
Values of the EXPRESS data type SET may be defined by EXPRESS constants. The value shall be mapped using the value defined for that instance in the EXPRESS schema. The value of the instance shall be compatible with the EXPRESS type.
NOTE If, in a particular entity instance, no value is provided for an OPTIONAL attribute whose data type is a SET, the attribute is encoded by a dollar sign ("$"), as specified in 12.2.2, and not as an empty list.
EXAMPLE Entity definition in EXPRESS:
ENTITY widget; a_number: SET OF INTEGER; END_ENTITY;
Sample entity instance in data section:
#2 = WIDGET((0,1,2)); --------> A #3 = WIDGET((0,$,2)); --------> B #4 = WIDGET((0,0,2)); --------> C
A: The attribute a_number was defined by the set numbers 0, 1, 2 in this instance.
B: Syntactically the instance is correct. However, the instance is incorrect with respect to the definition of a SET in EXPRESS because a SET is not allowed to have missing members.
C: Syntactically the instance is correct. However, the instance is incorrect with respect to the definition of a SET in EXPRESS because a SET is not allowed to have duplicate members.
Values of the EXPRESS data type BAG shall be mapped to the exchange structure as a list data type. Clause 7 describes the composition of a list data type. Within the list, each instance of the element type shall be encoded as specified in clause 12 for that EXPRESS data type. If the BAG is empty, the list shall be encoded as a left parenthesis ("(") followed by a right parenthesis (")").
Values of the EXPRESS data type BAG may be defined in the reference section. The value shall be mapped using the value instance name defined for that instance in the reference section. The value of the instance shall be compatible with the EXPRESS type.
Values of the EXPRESS data type BAG may be defined by EXPRESS constants. The value shall be mapped using the value defined for that instance in the EXPRESS schema. The value of the instance shall be compatible with the EXPRESS type.
NOTE If, in a particular entity instance, no value is provided for an OPTIONAL attribute whose data type is a BAG, the attribute is encoded by a dollar sign ("$"), as specified in 12.2.2, and not as an empty list.
EXAMPLE Entity definition in EXPRESS:
ENTITY widget; a_numbers: BAG OF INTEGER; END_ENTITY;
Sample entity instance in data section:
#2 = WIDGET((0,1,1,2)); --------> A #3 = WIDGET((0,$,2)); --------> B
A: The attribute a_numbers was defined by the collection of numbers 0, 1, 1, 2 in this instance.
B: Syntactically, the instance is correct. However, the instance is incorrect with respect to the definition of BAG in EXPRESS because a BAG is not allowed to have missing members.
A simple defined type is a type defined by an EXPRESS type declaration in which the underlying type is neither an ENUMERATION nor a SELECT. A simple defined type shall be mapped to the exchange structure as the data type used in its definition.
EXAMPLE Entity definition in EXPRESS:
TYPE type1 = INTEGER; END_TYPE; TYPE type2 = LIST [1 : 2] of REAL; END_TYPE; ENTITY widget; attribute1: LOGICAL; ------------> A attribute2: TYPE1; ------------> B attribute3: TYPE2; ------------> C END_ENTITY;
Sample entity instance in data section:
#4 = WIDGET( .T., 256, (1.0,0.0)); ^ ^ ^ | | | A B C
A: The value of the attribute attribute1; in this instance, TRUE.
B: Type1 is an integer type and, therefore, the value 256 is valid.
C: Type2 is a list and, therefore, a list with 2 REAL elements is valid.
Values of an EXPRESS ENUMERATION data type shall be mapped to the exchange structure as an enumeration data type. 6.4.5 describes the composition of a enumeration data type.
If the document that defines the schema whose instances are the subject of the data section also defines a set of short names for the enumerated values within that schema, the actual value in an instance of the ENUMERATION may be the short name corresponding to one of the enumerated values in the EXPRESS schema. Otherwise, the actual value shall be one of the enumerated values in the EXPRESS schema. In either case, any small letters shall be converted to the corresponding capital letters, and the value shall be delimited by full stops "." as defined in the ENUMERATION production of Table 2.
EXAMPLE Entity definition in EXPRESS:
TYPE primary_colour = ENUMERATION OF (red, green, blue); END_TYPE; ENTITY widget; p_colour: primary_colour; ---------------> A END_ENTITY;
Sample entity Instance in data section:
#2 = WIDGET(.RED.); ^ | A
A: The value of the attribute p_colour in this entity instance is RED.
An EXPRESS select data type defines a list of data types, called the "select-list", whose values are valid instances of the select data type. An instance of a select data type shall be a value of at least one of the data types in the select-list. The value shall be encoded in the exchange structure as determined by the following procedure:
For instances of simple defined types and enumeration data types, the KEYWORD shall identify the data type of the instance. The data type identified shall be one of the types in the select-list. If the document that defines the schema whose instances are the subject of the data section also defines a set of short names for the simple defined types and enumeration types within that schema, the KEYWORD may be the short name corresponding to the data type of the instance. Otherwise, the KEYWORD shall be the name of the simple defined type or enumeration data type itself. In either case, any small letters shall be converted to the corresponding capital letters, i.e., the encoding shall not contain any small letters.
NOTE 1 If the data type (in the select-list) which the value instantiates is itself a select data type, then this clause will be used recursively to encode the value. Only instances of entity data types, simple defined types and enumeration data types can actually be encoded (see Example 2).
NOTE 2 According to ISO 10303-11, an instance of a subtype of an entity data type is an instance of the entity data type. So "an instance of an entity data type in the select list" includes instances of subtypes of those entity data types.
NOTE 3 If the entity data types in the select-list are not mutually exclusive, then a value of the select data type may instantiate more than one entity data type in the select-list (see Example 1).
NOTE 4 If the value is not an entity instance, it is an instance of exactly one simple defined-type or enumeration data type. The value may, however, be a valid instance of several (nested) select data types and thereby instantiate more than one type in the original select-list (see Example 2).
EXAMPLE 1 Entity definition in EXPRESS:
ENTITY Leader SUBTYPE OF (Employee); project: STRING; END_ENTITY; ENTITY Manager SUBTYPE OF (Employee); unit: STRING; END_ENTITY; ENTITY Employee; name: STRING; END_ENTITY; TYPE Supervisor = SELECT (Manager, Leader); END_TYPE; ENTITY Meeting; date: STRING; attendees: SET [2:?] OF Supervisor; END_ENTITY;
Sample data section instances:
#1 = LEADER('J. Brahms','Academic Festival'); #2 = MANAGER('S. Ozawa', 'Tokyo Symphony'); #3 = (EMPLOYEE('G. Verdi') LEADER('Aida') MANAGER('La Scala')); #4 = MEETING('14921012', (#1, #2, #3));
The second attribute of instance #4 is the attendees: a SET OF Supervisor. Instance #1 is a Leader and thus a valid Supervisor. Instance #2 is a Manager and thus a valid Supervisor. Instance #3 is an instance of both (entity) types Leader and Manager from the select-list of Supervisor. All are mapped according to 6.4.4.
EXAMPLE 2 Entity definition in EXPRESS:
TYPE Mass = SELECT (Mass_Spec, Mass_Substitute); END_TYPE; TYPE Mass_Spec = SELECT (Measured_Mass, Computed_Mass, Estimated_Mass); END_TYPE; TYPE Measured_Mass = REAL; END_TYPE; TYPE Computed_Mass = Extended_Real; END_TYPE; TYPE Estimated_Mass = REAL; END_TYPE; TYPE Mass_Substitute = SELECT(Weight, Estimated_Mass); END_TYPE; TYPE Weight = REAL; END_TYPE; TYPE Extended_Real = SELECT (FloatingNumber, NotaNumber); END_TYPE; TYPE FloatingNumber = REAL(7); END_TYPE; TYPE NotaNumber = ENUMERATION OF (plus_infinity, minus_infinity, indeterminate, invalid); END_TYPE; ENTITY Steel_Bar; bar_length: Extended_Real; bar_mass: Mass; END_ENTITY;
Sample instantiation in data section:
#1 = STEEL_BAR(FLOATINGNUMBER(77.0), MEASURED_MASS(13.25)); #2 = STEEL_BAR(NOTANUMBER(.INDETERMINATE.), ESTIMATED_MASS(10.0)); #3 = STEEL_BAR(FLOATINGNUMBER(77.0), COMPUTED_MASS(FLOATINGNUMBER(14.77719)));
The first attribute of instance #1 represents an Extended_Real value that is a FloatingNumber. It is mapped (following 12.1.8 for the select data type Extended_Real) as a TYPED_PARAMETER with KEYWORD FLOATINGNUMBER (the simple defined type in the select-list). The PARAMETER value 77.0 is mapped to the exchange structure, following 12.1.6 for FloatingNumber, as a value of the simple type REAL.
The second attribute of instance #1 represents a Measured_Mass value, which is a valid Mass_Spec value and therefore a valid Mass value. It is mapped (by recursive application of 12.1.8, since Mass is a select data type and Mass_Spec is a select data type) as a TYPED_PARAMETER with KEYWORD MEASURED_MASS (the simple defined type in the select-list). The PARAMETER value 13.25 is mapped to the exchange structure, following 12.1.6 for Measured_Mass, as a value of the simple type REAL.
The first attribute of instance #2 represents an Extended_Real value that is a NotaNumber value. It is mapped (following 12.1.8 for Extended_Real) as a TYPED_PARAMETER with KEYWORD NOTANUMBER (the enumeration type in the select-list). The PARAMETER value "indeterminate" is mapped to the exchange structure, following 12.1.7 for the enumeration type NotaNumber.
The second attribute of instance #2 represents an Estimated_Mass value. This is a valid Mass_Spec value and also a valid Mass_Substitute value and therefore a valid value of Mass. This value actually instantiates both (select) data types in the select-list of Mass. It is mapped (by recursive application of 12.1.8, since Mass is a select data type and Mass_Spec is a select data type) as a TYPED_PARAMETER with KEYWORD ESTIMATED_MASS (the simple defined type in the select-list). The PARAMETER value 10.0 is mapped to the exchange structure, following clause 12.1.6 for Estimated_Mass, as a value of the simple type REAL.
The first attribute of instance #3 is the same as the first attribute of instance #1.
The second attribute of instance #3 represents a Computed_Mass value, which is a valid Mass_Spec value and therefore a valid Mass value. It is mapped (by recursive application of 12.1.8, since Mass is a select data type and Mass_Spec is a select data type) as a TYPED_PARAMETER with KEYWORD COMPUTED_MASS (the simple defined type in the select-list). The PARAMETER value encoding follows clause 12.1.6 for a value of Computed_Mass, which is an Extended_Real value. Extended_Real is a select data type. Per clause 12.1.8, the Extended_Real value is encoded as a TYPED_PARAMETER with KEYWORD FLOATINGNUMBER and PARAMETER value 14.77719, following clause 12.1.6 for FloatingNumber.
An instance of an EXPRESS entity data type shall be mapped to the exchange structure as an ENTITY_INSTANCE.
As defined by ISO 10303-11, a "simple entity instance" is an entity instance that is not an instance of a subtype of any entity data type. All other entity instances are called "complex entity instances". A simple entity instance shall be mapped as specified in 12.2.1. A complex entity instance shall be mapped as specified in 12.2.5.
NOTE 1 A simple entity instance is an entity instance which is completely described by a single EXPRESS entity-declaration. A complex entity instance is an instance whose description involves more than one entity-declaration, even when only one of them contains explicit attributes. A simple entity instance can be an instance of a supertype, as long as it is not an instance of any subtype, but an instance of a subtype is always "complex".
Only the explicit attributes of an EXPRESS entity are mapped to the exchange structure. Special provisions, however, apply to OPTIONAL explicit attributes (see 12.2.2), explicit attributes whose values are entity instances (see 12.2.4), and all redeclarations of explicit attributes (see 12.2.6, 12.2.7, and 12.2.8)
NOTE 2 More than one such provision may apply to the same attribute.
A simple entity instance shall be mapped as a SIMPLE_ENTITY_INSTANCE in the exchange structure. The entity data type name shall be mapped to the KEYWORD of the SIMPLE_RECORD, as specified in 12.2.11.
Each explicit attribute shall be mapped directly to a PARAMETER of the SIMPLE_RECORD in the exchange structure. The order of the PARAMETERs in the exchange structure shall be the same as the order of the corresponding attributes in the EXPRESS entity declaration. The first PARAMETER shall be the value of the first explicit attribute; the second PARAMETER shall be the value of the second explicit attribute, and so on. If the EXPRESS entity data type has no explicit attributes, the PARAMETER_LIST shall be empty.
The form of each PARAMETER shall depend on the data type of the corresponding attribute, as specified in 12.1.
EXAMPLE Definition in EXPRESS:
TYPE primary_colour_abbreviation = ENUMERATION OF (r, g, b); END_TYPE; ENTITY widget; -----------------------------> A attribute1: INTEGER; ---------------------> B attribute2: STRING; ---------------------> C attribute3: LOGICAL; ---------------------> D attribute4: BOOLEAN; ---------------------> E attribute5: REAL; ------------------------> F attribute6: LIST [1 : 2] of LOGICAL; ----> G attribute7: ARRAY [-1:3] of INTEGER; ---> H attribute8: PRIMARY_COLOUR_ABBREVIATION; -> I END_ENTITY;
Sample entity instance in data section:
#1 = WIDGET( 1, 'A', .T., .F., 1.0, (.T.,.F.), (1,0,1,2,3), .R.); ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | A B C D E F G H I
A: The EXPRESS entity name widget is mapped to the WIDGET standard keyword of the data section entity.
B: attribute1 has a value of 1 in this entity instance.
C: attribute2 has a value of A in this entity instance.
D: attribute3 has a value of T in this entity instance.
E: attribute4 has a value of F in this entity instance.
F: attribute5 has a value of 1.0 in this entity instance.
G: attribute6 is a list of logicals in this entity instance. The list values are:
ATTRIBUTE6(1) = T ATTRIBUTE6(2) = F
H: attribute 7 is an array of integers in this entity instance. The array values are:
ATTRIBUTE7(-1) = 1 ATTRIBUTE7( 0) = 0 ATTRIBUTE7( 1) = 1 ATTRIBUTE7( 2) = 2 ATTRIBUTE7( 3) = 3
I: Attribute 8 is an enumeration. The attribute contains a value of R.
An explicit attribute that is declared to be OPTIONAL is not required to have a value in a given entity instance. When the optional value is supplied in an entity instance, it shall be encoded according to the data type of the attribute, as specified in 12.1. When the optional value is not supplied in an entity instance, the missing attribute value shall be encoded in the exchange structure as the dollar sign "$".
EXAMPLE Entity definition in EXPRESS:
ENTITY xxx; attribute1: REAL; attribute2: REAL; END_ENTITY; ENTITY yyy; ------------------------> A attribute1: OPTIONAL LOGICAL; -----> B attribute2: xxx; -----------------> C attribute3: xxx; -----------------> D attribute4: OPTIONAL INTEGER; -----> E attribute5: OPTIONAL REAL; -------> F END_ENTITY;
Sample entity instances in data section:
#1=XXX(1.0,2.0); #2=XXX(3.0,4.0); #3=YYY($,#2,#1,$,$); ^ ^ ^ ^ ^ ^ | | | | | | A B C D E F
A: The EXPRESS entity name yyy is mapped to the YYY standard keyword of the data section entity.
B: attribute1 does not have a value in this entity instance.
C: attribute2 is a reference to the xxx entity with entity instance #2.
D: attribute3 is a reference to the xxx entity with entity instance #1.
E: attribute4 does not have a value in this entity instance.
F: attribute5 does not have a value in this entity instance.
The derived attributes of an entity shall not be mapped to the exchange structure. When a derived attribute in a subtype redeclares an attribute in a supertype, the mapping used shall be as described in 12.2.6.
EXAMPLE Entity definition in EXPRESS:
ENTITY yyy; q0: Real; q1: Real; q2: Real; END_ENTITY; ENTITY xxx; ---------------------------> A p0: yyy; ---------------------------> B p1: yyy; ---------------------------> C p2: yyy; ---------------------------> D DERIVE attrib5 : vector := func_normal (p0,p1,p2); ----> E attrib4 : real := func_diameter (p0,p1,p2); --> F END_ENTITY;
Sample entity instances in data section:
#9 = YYY( 0.0, 0.0, 0.0); #10 = YYY( 1.0, 2.0, 3.0); #11 = YYY( 4.0, 5.0, 6.0); #12 = XXX( #9, #10, #11); ^ ^ ^ ^ | | | | A B C D
A: The EXPRESS entity name xxx is mapped to the standard keyword of the data section entity.
B: p0 is a reference to the yyy entity with an entity instance #9.
C: p1 is a reference to the yyy entity with an entity instance #10.
D: p3 is a reference to the yyy entity with an entity instance #11.
E: attrib5 does not map to the entity instance because it is a derived attribute.
F: attrib4 does not map to the entity instance because it is a derived attribute.
If an entity instance is specified as an attribute of a second (referencing) entity instance, the first (referenced) entity instance shall be mapped to the exchange structure as an instance name (see 6.4.4). The referenced entity instance shall be defined within the EXPRESS schema, the reference section or one of the data sections, i.e. somewhere within the EXPRESS schema, reference or data sections the referenced entity instance shall occur on the left of the equals sign "=". This definition may precede or follow the use of the entity instance as an attribute. The definition need not occur within the same data section as the use of the entity instance as an attribute.
NOTE 1 As per 6.4.4.1 if the referenced instance is defined by an EXPRESS constant then the first character of its name will be an UPPER letter.
NOTE 2 Annex E describes methods for evaluating schema conformance when an exchange structure contains multiple data sections based on different EXPRESS schemas, including the validity of references among entity instances defined in data sections based on different EXPRESS schemas.
EXAMPLE Entity definition in EXPRESS:
ENTITY yyy; x : REAL; y : REAL; z : REAL; END_ENTITY; ENTITY xxx; p0 : yyy; --------------> A p1 : yyy; --------------> B END_ENTITY;
Sample entity instance in data section:
#1 = YYY(3., 4., 5.); #2 = XXX (#1, #3); #3 = YYY (1., 2., 3.);
ISO 10303-11 defines instances of an entity having a SUBTYPE clause to be "complex entity instances", in that they may involve attributes from more than one entity-type declaration. This subclause specifies how complex entity instances are mapped to the exchange structure.
Complex entity instances shall be mapped to the exchange structure using one of two mapping rules, internal mapping or external mapping. One mapping rule applies to each instance of a subtype entity. The selection of which mapping rule to use for each entity instance is prescribed by 12.2.5.1.
NOTE 1 The selection of mapping depends on the entity instance rather than the entity type. It is possible for different instances of the same entity data type to use different mappings, depending on whether they are instances of subtypes and which subtypes they instantiate.
NOTE 2 This subclause applies only to complex entity instances. It does not necessarily apply to every instance of a supertype entity. In particular, it does not apply to an instance of a supertype that is not an instance of any subtype. Such instances may exist if the supertype is not an abstract supertype and is not itself a subtype of some other entity. Such instances are mapped as provided in 12.2.1.
A set of entity data type definitions that are linked by subtype and implicit or explicit supertype expressions define a set of complex entity instance structures, referred to as the evaluated set in annex B of ISO 10303-11. Each member of the evaluated set specifies a list of entity data type names.
Each particular instance of an entity data type corresponds to one member of the evaluated set. The mapping that may be applied to a particular instance depends on the member of the evaluated set to which it corresponds.
To determine the mapping rules to apply to a given entity instance:
NOTE At least one entity data type will be identified in step b above.
If the internal mapping is used, the entity instance shall be mapped to a SIMPLE_ENTITY_INSTANCE (see Table 3). The KEYWORD shall encode the name of the leaf entity data type, as specified in 12.2.11. The PARAMETER_LIST shall encode the values of the inherited explicit attributes of all supertype entities and the explicit attributes of the leaf entity data type. The order in which the inherited and explicit attributes appear in the exchange structure shall be determined as follows:
This procedure may result in a supertype entity being referenced more than once. In this case all references after the first one shall be ignored.
EXAMPLE 1 An example of a simple subtype/supertype relationship. Entity definition in EXPRESS:
ENTITY aa ABSTRACT SUPERTYPE OF (ONEOF(bb,cc)); ------> A attrib_a: zz; --------------------------------------> B END_ENTITY; ENTITY bb SUBTYPE OF (aa) ABSTRACT SUPERTYPE OF (ONEOF(xx)); ------------> C attrib_b1: yy; -------------------------------------> D attrib_b2: yy; -------------------------------------> E END_ENTITY; ENTITY cc SUBTYPE OF (aa); attrib_c : REAL; END_ENTITY; ENTITY xx SUBTYPE OF (bb); attrib_x: REAL; -----------------------------------> F END_ENTITY; ENTITY zz; attrib_z : STRING; END_ENTITY; ENTITY yy; attrib_1 : REAL; attrib_2 : REAL; attrib_3 : REAL; END_ENTITY;
Sample entity instance of entity data type xx in data section:
#1 = ZZ('ZATTR'); #2 = YY(1.0, 2.0, 0.0); #3 = YY(2.0, 2.0, 0.0); #4 = XX(#1, #2, #3, 4.0); ^ ^ ^ ^ | | | | B D E F
A: Because entity aa is an abstract supertype it does not map to the exchange structure.
B: The attribute attrib_a will map to the data section as an inherited attribute in an entity that is directly or indirectly subtyped to the aa entity. In this case, attrib_a is represented by the first attribute of the instance of xx, and refers to zz, entity instance #1.
C: Because entity bb is an abstract supertype it will not map to the exchange structure.
D: The attribute attrib_b1 will map to the data section as an inherited attribute in an entity that is directly or indirectly subtyped to the bb entity. In this case, attrib_b1 is represented by the second attribute of the instance of entity xx, and refers to yy, entity instance #2.
E: The attribute attrib_b2 will map to the data section as an inherited attribute in an entity that is directly or indirectly subtyped to the bb entity. In this case, attrib_b2 is represented by the third attribute of the instance of entity xx, and refers to yy, entity instance #3.
F: Attribute attrib_x is represented by its value 4.0 .
EXAMPLE 2 An example of the mapping of a supertype that is not an ABSTRACT supertype. Entity definition in EXPRESS:
ENTITY aa SUPERTYPE OF (ONEOF(bb,dd)); --> A attrib_a : STRING; END_ENTITY; ENTITY bb SUBTYPE OF (aa); ---------------> B END_ENTITY; ENTITY cc SUBTYPE OF (bb); --------------> C attrib_c : INTEGER; END_ENTITY; ENTITY dd SUBTYPE OF (aa); --------------> D attrib_d : REAL; END_ENTITY; ENTITY ee ; -----------------------------> E attrib_e : aa; END_ENTITY;
Sample entity instance in data section:
#1 = AA('SAMPLE STRING'); ---------------> A #2 = BB('ABC'); -------------------------> B #3 = CC('DEF', 123); -------------------> C #4 = DD('XYZ', 99.99); -------------------> D #5 = EE(#1); -----------------------------> E #6 = EE(#2); -----------------------------> E #7 = EE(#3); -----------------------------> E #8 = EE(#4); -----------------------------> E
A: Since it was not an abstract supertype, the supertype entity aa can be instantiated in an exchange structure and notice that it contains only its attrib_a attribute when it is instantiated.
B: The entity bb is a subtype of aa and therefore its instances will contain the attributes of both aa and bb, but since entity bb does not define any attributes the parameter list will only contain attrib_a.
C: The entity cc is a subtype of bb and therefore its instances will contain the attributes of aa, bb, and cc.
D: The entity dd is a subtype of aa and therefore its instances will contain the attributes of both aa and dd.
E: The entity ee references entity aa as an attribute. Therefore, an instance of entity ee may reference any of #1, #2, #3 or #4.
EXAMPLE 3 An example of the mapping of an entity with multiple supertypes in the SUBTYPE OF expression. Entity definition in EXPRESS:
ENTITY base SUPERTYPE OF (branch_one,branch_two); ---> A attrib_a : STRING; END_ENTITY; ENTITY branch_one SUBTYPE OF (base); -----------------> B attrib_b : INTEGER; END_ENTITY; ENTITY branch_two SUBTYPE OF (base); ----------------> C attrib_c : BOOLEAN; END_ENTITY; ENTITY leaf SUBTYPE OF (branch_one, branch_two); ----> D attrib_d : REAL; END_ENTITY;
Sample entity instance in data section:
#1 = BASE('SAMPLE STRING'); -------------------------> A #2 = BRANCH_ONE('ABC', 123); ------------------------> B #3 = BRANCH_TWO('DEF', .T.); -----------------------> C #4 = LEAF('XYZ', 123, .T., 99.99); -------------------> D
A: Entity base has no supertypes. When instantiated in an exchange structure, its parameter list will contain only a value for the attrib_a attribute.
B: The entity branch_one is a subtype of base. When instantiated in an exchange structure, its parameter list will contain the inherited attributes of base followed by the attributes of branch_one.
C: The entity branch_two is a subtype of base. When instantiated in an exchange structure, its parameter list will contain the inherited attributes of base followed by the attributes of branch_two.
D: The entity leaf is a subtype of branch_one and branch_two. When instantiated in an exchange structure, its parameter list will contain the inherited attributes of branch_one, which includes the attributes of base, followed by the inherited attributes of branch_two, followed by the attributes of leaf. The attributes of base are only written once, while writing the attributes of branch_one. They are ignored when they are encountered a second time when writing the attributes of branch_two.
If the external mapping is used, the entity instance shall be mapped to a COMPLEX_ENTITY_INSTANCE (see Table 3).
ISO 10303-11 defines a "partial (complex) entity value" to be the set of attribute values described by a single EXPRESS entity declaration. Every entity data type name in the evaluated set member identifies a partial complex entity value of the entity instance. Thus, the evaluated set member identifies the set of partial complex entity values that, together with the instance name, completely describe the entity instance.
Every partial complex entity value identified by an entity data type name in the evaluated set member shall be mapped to a SIMPLE_RECORD within the SUBSUPER_RECORD. The order of SIMPLE_RECORDs within the SUBSUPER_RECORD shall be in ascending sequence of their entity data type names. The names shall be collated as UPPER and DIGIT characters using the octet values defined in 5.2.
Each SIMPLE_RECORD shall encode one partial complex entity value. In each SIMPLE_RECORD, the KEYWORD shall encode the corresponding entity data type name, as specified in 12.2.11, and the PARAMETER_LIST shall encode the values of the explicit attributes, if any, appearing in the corresponding entity declaration. The order of the PARAMETERs in the exchange structure shall be the same as the order of the corresponding attributes in the EXPRESS entity declaration. If the EXPRESS entity declaration contains no explicit attributes, the PARAMETER_LIST shall be empty. The form of each PARAMETER shall depend on the data type of the corresponding attribute, as specified in 12.1.
NOTE 1 The sequence of partial entity values (SIMPLE_RECORDs) is determined by the entity data type name (the so-called "long name") and not by the "short name", if provided, which may be used for the encoding.
NOTE 2 Every partial entity value in the evaluated set is required to appear, including supertypes which have no explicit attributes.
EXAMPLE 1 An example of the mapping of subtypes related by ANDOR.
Entity definition in EXPRESS:
ENTITY aa SUPERTYPE OF (bb ANDOR cc); --> A attrib_a : STRING; END_ENTITY; ENTITY bb SUBTYPE OF (aa); --------------> B attrib_b : INTEGER; END_ENTITY; ENTITY cc SUBTYPE OF (aa); -------------> C attrib_c : REAL; END_ENTITY; ENTITY dd ; ----------------------------> D attrib_d : aa; END_ENTITY;
Sample entity instance in data section:
#1 = BB('sample string', 15); ------------> A #2 = CC('S', 3.0); ------------------------> B #3 = (AA('ASTRID')BB(17)CC(4.0)); ---------> C #4 = DD(#1); ------------------------------> D #5 = DD(#2); ------------------------------> D #6 = DD(#3); ------------------------------> D #7 = AA('ABC'); ---------------------------> E
A: #1 is an instance of aa and bb combined.
B: #2 is an instance of aa and cc combined.
C: #3 is an instance of aa, bb and cc combined.
D: The entity dd references entity aa as an attribute. Therefore, an instance of entity dd may legally reference any of #1, #2 or #3.
E: The non-abstract supertype aa can be instantiated, and the internal mapping applies because the evaluated set contains only one member.
EXAMPLE 2 An example of the mappings of a more complicated subtype/supertype graph. Entity definition in EXPRESS:
ENTITY x; attrib_x : INTEGER; END_ENTITY; ENTITY a ABSTRACT SUPERTYPE OF(ONEOF(b,c)); --> A attrib_a : x -------------------------------> B END_ENTITY; ENTITY b SUPERTYPE OF(d ANDOR e) SUBTYPE OF (a); attrib_b : REAL; ---------------------------> B END_ENTITY; ENTITY c SUBTYPE OF (a); ---------------------> C attrib_c : REAL; END_ENTITY; ENTITY d SUBTYPE OF (b); ---------------------> D attrib_d : x; END_ENTITY; ENTITY e ABSTRACT SUPERTYPE SUBTYPE OF (b); ------------------------> A attrib_e : x; ------------------------------> B END_ENTITY; ENTITY f SUPERTYPE OF (h); attrib_f : x; ------------------------------> B END_ENTITY; ENTITY g SUBTYPE OF (e); ---------------------> E attrib_g : INTEGER; END_ENTITY; ENTITY h SUBTYPE OF (e,f); -------------------> E attrib_h : INTEGER; END_ENTITY;
A: Since entity a and e are abstract supertypes they cannot occur on the exchange structure as independent instances.
B: Since attrib_a, attrib_b, attrib_e and attrib_f are attributes of supertype entities, they will be mapped as inherited attributes if a subtype is mapped using the internal mapping. They will be mapped as attributes of the entities in which they are declared if a subtype is mapped using the external mapping.
C: Since entity c participates in an ONEOF operation and its supertype participates in no supertype operation, it will use the internal mapping.
D: The mapping of d will depend on the structure of the evaluated set in which it appears.
E: Since entities g and h both have a supertype (entity e) that participates in an ANDOR operation. their mapping will depend on the structure of the evaluated set in which they appear.
EXAMPLE 3 An entity instance showing internal mapping.
#1=X(1); #2=C(#1, 2.0); ^ ^ ^ | | | A B C
A: The evaluated set of '#2' is [c & a] and therefore uses the internal mapping.
B: attrib_a is inherited by entity data type c. The evaluated set is a reference to an instance of entity data type x.
C: attrib_c appears after all inherited attributes.
EXAMPLE 4 Entity instance showing internal mapping:
#4=X(3); #1=X(1); #2=D(#1, 2.0, #4) ^ ^ ^ ^ | | | | A B C D
A: Since entity instance #2 belongs to the evaluated set [a & b & d] that has exactly one leaf (d), it is internally mapped.
B: The attribute of a with name attrib_a is inherited by entity data type d.
C: attrib_b is inherited by entity data type d.
D: attrib_d is the last attribute in the d instance because inherited attributes from the supertype entities a and b come first.
EXAMPLE 5 Entity instance showing external mapping:
#1=X(1); #2=(A(#1) B(9.0) D(#1) E(#1) F(#1) H(4) ); -------------> A
A: Since entity instance #2 is a member of [a & b & d & e & f & h] and this evaluated set has more than one leaf (d and h), external mapping is used. There is no single entity data type name that can be associated with the entity; rather it can be considered to have the composite name a-b-d-e-f-h. The spaces between the entity records are optional and have been added to this example for ease of reading.
If a subtype entity redeclares an attribute of its supertype using the DERIVE clause and if the original attribute is an explicit attribute, the value of the original attribute in the supertype shall be encoded as an asterisk ("*").
EXAMPLE Entity definition in EXPRESS:
ENTITY point; x : REAL; y : REAL; z : REAL; END_ENTITY; ENTITY point_on_curve SUBTYPE OF (point); u : REAL; c : curve; DERIVE SELF\point.x : real := fx(u, c); SELF\point.y : real := fy(u, c); SELF\point.z : real := fz(u, c); END_ENTITY; ENTITY curve; attr : STRING; END_ENTITY;
Sample entity instance in data section
#1 = CURVE('curve_attribute'); #2 = POINT_ON_CURVE( *, *, *, 0.55, #1); -----------> A #3 = POINT(2.0, 3.0, 4.0); -------------------------> B
A: Because a subtype with derived attributes is used here, the attributes x, y and z are replaced by asterisks.
B: Because POINT is not an ABSTRACT SUPERTYPE, it is possible to have an instance of POINT in the exchange structure. The attributes x, y, and z appear as normal.
If a subtype entity redeclares an attribute of its supertype using the INVERSE clause, there is no effect on the encoding. The redeclared attribute is not encoded in any way.
If a subtype entity redeclares an attribute of one of its supertypes as an explicit attribute, i.e. not in a DERIVE clause nor an INVERSE clause, there is no effect on the encoding.
The attribute value shall be encoded as an attribute of the supertype, as specified in 12.2.5, applying the mapping specified in clause 12 for the data type of the attribute in the supertype. The redeclared attribute shall be ignored, that is, it shall not be considered an attribute of the subtype for encoding purposes.
EXAMPLE Entity definition in EXPRESS:
ENTITY aaa SUPERTYPE OF (ONEOF (bbb, ccc)); a1 : NUMBER; a2 : curve; INVERSE a3 : SET OF mmm FOR m1; END_ENTITY; ENTITY bbb SUBTYPE OF (aaa); SELF\aaa.a1 : INTEGER; b : REAL; END_ENTITY; ENTITY ccc SUBTYPE OF (aaa); SELF\aaa.a2 : line; INVERSE SELF\aaa.a3 : SET [1:2] OF mmm FOR m1; END_ENTITY; ENTITY curve; ... END_ENTITY; ENTITY line SUBTYPE OF (curve); ... END_ENTITY; ENTITY mmm; m1 : aaa; END_ENTITY;
Sample instantiation in data section:
#1 = LINE(...); #2 = CURVE(...); #3 = BBB(1.0, #2, 0.5); #4 = CCC(1.5, #1);
For the instances #3 and #4 the encoding is the same as if there were no redeclared attributes in the entities bbb and ccc.
Entity local rules, WHERE rules and UNIQUE rules, shall not be mapped to the exchange structure.
EXAMPLE Entity definition in EXPRESS:
ENTITY widget; -----------------------> A a : REAL; --------------------------> B b : REAL; --------------------------> C c : REAL; --------------------------> D WHERE a ** 2 + b ** 2 + c ** 2 = 3.0; ----> E END_ENTITY;
Sample entity instance in data section.:
The WHERE rules are not instantiated in the entity instance.
#2 = WIDGET( 1.0, 1.0, 2.0 ); ^ ^ ^ ^ | | | | A B C D
A: The EXPRESS entity name widget is mapped to the entity data type keyword of the data section entity.
B: Attribute a has a value of 1.0 in the entity instance.
C: Attribute b has a value of 1.0 in the entity instance.
D: Attribute c has a value of 2.0 in the entity instance.
E: The WHERE rule did not map to the exchange structure. The entity is syntactically correct. However, the WHERE rule is not satisfied by the values of the three attributes.
Attributes within the INVERSE clause shall not be mapped to the exchange structure.
If the document that defines the schema whose instances are the subject of a data section also defines a set of short names for each of the entity data types within that schema, these short names may be used as the encoding of the entity data type names. Otherwise, the encoding of the entity data type names shall be the entity data type names themselves. In either case, any small letters shall be converted to their corresponding capital letters, i.e., the encoding shall not contain any small letters.
The EXPRESS element of SCHEMA shall not be mapped to the exchange structure. The name of the schema that specifies entities that appear in an exchange structure shall be mapped to the header section of the exchange structure by use of an instance of the file_schema entity data type as specified in 8.2.4.
Each reference to an EXPRESS element of CONSTANT shall be mapped to a constant instance name (see 6.4.4.1) or a constant value name (see 6.4.4.2).
The EXPRESS element of RULE shall not be mapped to the exchange structure.
Remarks shall not be mapped to the exchange structure.
© ISO 2016 — All rights reserved