Foreword
NOTE This document is developed and published by the EXPRESS Language Foundation. All rights reserved.
The EXPRESS Language Foundation, maintainer of the EXPRESS data modeling language, develops and maintains language standards and technologies. The work of preparing EXPRESS standards is carried out through technical working groups. Each member interested in a subject for which a working group has been established has the right to participate in that group. International organizations, both governmental and non-governmental, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described in the EXPRESS Language Foundation’s documentation guidelines. In particular, different approval criteria are needed for different types of documents. This document was drafted in accordance with the EXPRESS Language Foundation’s editorial rules and guidelines.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The EXPRESS Language Foundation shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction.
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
For an explanation of the voluntary nature of standards and the meaning of EXPRESS Language Foundation specific terms and expressions related to conformity assessment, please refer to the Foundation’s documentation guidelines.
This document was prepared by the EXPRESS Language Foundation’s Technical Working Group.
EXPRESS is organized as a series of specifications, each published separately. The structure of EXPRESS is described in the Core Language Specification.
Each specification is a member of one of the following series: description methods, implementation methods, conformance testing methodology and framework, integrated generic resources, integrated application resources, application protocols, abstract test suites, application interpreted constructs, and application modules. This part is a member of the description methods series.
Introduction
EXPRESS-Q is a query language designed to work with EXPRESS schemas, particularly in the context of STEP (Standard for the Exchange of Product model data) application protocols. It provides a formal mechanism for defining mappings between Application Reference Model (ARM) and Model Implementation Model (MIM) schemas, as well as specifying constraints on datasets that comply with these schemas.
The primary purpose of EXPRESS-Q is to bridge the gap between conceptual models (ARM) and their implementations (MIM), ensuring that data exchange between different systems maintains semantic consistency. By providing a standardized way to express these mappings and constraints, EXPRESS-Q facilitates more robust and reliable data exchange in complex engineering and manufacturing environments.
EXPRESS Language Foundation — EXPRESS Query Language Specification
1 Scope
This document specifies EXPRESS-Q, including its syntax, semantics, and usage within the context of EXPRESS schemas and STEP application protocols.
The specification covers:
The grammar and syntax of EXPRESS-Q
The semantics of EXPRESS-Q constructs
The reference path syntax used for defining detailed mappings
Validation rules for EXPRESS-Q files
Guidelines for implementing EXPRESS-Q parsers and validators
This specification is intended for use by software developers, data modelers, and systems integrators working with EXPRESS schemas and STEP application protocols.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 10303-1:2024, Industrial automation systems and integration — Product data representation and exchange — Part 1: Overview and fundamental principles
ISO 10303-11:2004, Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual
ISO/IEC 8824-1:20081) , Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation — Part 1:
ISO/IEC 10646:20112) , Information technology — Universal Coded Character Set (UCS)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
ISO Online browsing platform: available at https://www.iso.org/obp
IEC Electropedia: available at https://www.electropedia.org
EXPRESS-Q
query language for EXPRESS schemas, used to define mappings and constraints between ARM and MIM schemas
4 EXPRESS-Q language specification
4.1 Overview
EXPRESS-Q is designed to work alongside EXPRESS schemas, providing a mechanism to define mappings between ARM and MIM schemas, as well as specifying constraints on datasets. The language uses a syntax similar to EXPRESS but introduces new constructs specific to querying and mapping.
An EXPRESS-Q file typically consists of one or more entity mappings, each of which defines how an ARM entity and its attributes correspond to MIM elements. These mappings can include various declarations such as extensibility, AIM elements, EXPRESS references, reference paths, and alternative mappings.
Entity names, AIM element names, and assertion targets use EXPRESS links to identify both the schema and element, enabling cross-document reference resolution in published documentation.
4.2 EBNF grammar
The following EBNF (Extended Backus-Naur Form) grammar defines the syntax of EXPRESS-Q:
express_q_file = { entity_mapping } ;
entity_mapping = "ENTITY_MAPPING" entity_ref ";" newline
[ extensible_decl ]
[ aim_element_decl ]
[ express_ref_decl ]
[ refpath_decl ]
[ alt_map_decl ]
{ attribute_mapping }
"END_ENTITY_MAPPING" ";" ;
extensible_decl = "EXTENSIBLE" ":" boolean ";" newline ;
aim_element_decl = "AIM_ELEMENT" ":" ( express_link | string ) ";" newline ;
express_ref_decl = "EXPRESS_REF" ":" "[" [ string { "," string } ] "]" ";" newline ;
refpath_decl = "REFPATH" ":" "{" newline
refpath_content
"}" ";" newline ;
refpath_content = { refpath_line } ;
refpath_line = [ indentation ] reference_expression newline ;
reference_expression = entity_reference [ relationship { relationship } ] ;
relationship = path_relation | supertype_relation | subtype_relation |
select_extension | constraint ;
entity_reference = identifier ;
path_relation = "->" entity_reference ;
supertype_relation = "=>" entity_reference ;
subtype_relation = "<=" entity_reference ;
select_extension = "*" ">" entity_reference | "<" "*" entity_reference ;
constraint = "[" constraint_expression "]" ;
constraint_expression = ? expression following EXPRESS syntax ? ;
indentation = ? one or more spaces or tabs ? ;
alt_map_decl = "ALT_MAP" ":" "[" [ string { "," string } ] "]" ";" newline ;
attribute_mapping = "ATTRIBUTE_MAPPING" attribute_name ";" newline
"ASSERTION_TO" ":" ( express_link | string ) ";" newline
[ aim_element_decl ]
[ express_ref_decl ]
[ refpath_decl ]
"END_ATTRIBUTE_MAPPING" ";" newline ;
entity_ref = express_link | entity_name ;
entity_name = identifier ;
attribute_name = identifier ;
express_link = "<<express:" schema_name "." element_name "," display_name ">>" ;
schema_name = identifier ;
element_name = identifier ;
display_name = identifier ;
identifier = letter { letter | digit | "_" } ;
boolean = "TRUE" | "FALSE" ;
string = '"' { character } '"' ;
letter = "A" | ... | "Z" | "a" | ... | "z" ;
digit = "0" | ... | "9" ;
character = ? any printable character ? ;
indentation = ? one or more spaces or tabs ? ;
newline = ? line break character(s) ? ;This grammar defines the overall structure of an EXPRESS-Q file, including entity mappings, attribute mappings, reference paths, including various types of relationships between entities and constraints, and various declarations.
4.3 Semantics
This section describes the meaning and usage of each major construct in EXPRESS-Q.
4.3.1 EXPRESS link
express_link = "<<express:" schema_name "." element_name "," display_name ">>" ;
An EXPRESS link is a cross-reference that identifies an element within a specific EXPRESS schema. It encodes the schema name, element name, and a display name used for rendering.
The schema origin of a referenced element is derived from the EXPRESS link, eliminating the need for a separate source declaration.
Usage
Use in entity mapping names to identify the ARM entity and its schema.
Use in AIM_ELEMENT declarations to identify the MIM entity and its schema.
Use in ASSERTION_TO declarations to identify the target entity and its schema.
The display_name is used for rendering in published documentation.
<<express:Activity_arm.Activity,Activity>>
<<express:action_schema.executed_action,executed_action>>
<<express:Activity_method_arm.Activity_method,Activity_method>>
4.3.2 Entity mapping
entity_mapping = "ENTITY_MAPPING" entity_ref ";" newline
[ extensible_decl ]
[ aim_element_decl ]
[ express_ref_decl ]
[ refpath_decl ]
[ alt_map_decl ]
{ attribute_mapping }
"END_ENTITY_MAPPING" ";" ;
An entity mapping defines how an ARM entity corresponds to one or more MIM entities or constructs. It encapsulates all the information needed to map a single ARM entity to its MIM counterpart(s).
The entity name shall be an EXPRESS link identifying the ARM entity and its schema, or a plain entity name for backward compatibility.
Usage
Begin with “ENTITY_MAPPING” followed by the ARM entity reference (EXPRESS link or plain name).
Include optional declarations for extensibility, AIM element, EXPRESS references, reference path, and alternative mappings.
Include attribute mappings for the entity’s attributes.
End with “END_ENTITY_MAPPING”.
ENTITY_MAPPING <<express:Activity_arm.Activity,Activity>>;
EXTENSIBLE: FALSE;
AIM_ELEMENT: "<<express:action_schema.executed_action,executed_action>>";
EXPRESS_REF: ["action_schema"];
REFPATH: {
executed_action <= action
};
ATTRIBUTE_MAPPING chosen_method;
ASSERTION_TO: "<<express:Activity_method_arm.Activity_method,Activity_method>>";
AIM_ELEMENT: "PATH";
REFPATH: {
executed_action
executed_action <= action
action.chosen_method -> action_method
action_method
};
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
4.3.3 Extensible declaration
extensible_decl = "EXTENSIBLE" ":" boolean ";" newline ;
The extensible declaration specifies whether the entity mapping is extensible, corresponding to the extensibility of SELECT types in EXPRESS schemas.
Usage
Use “EXTENSIBLE: TRUE;” for extensible mappings.
Use “EXTENSIBLE: FALSE;” for non-extensible mappings.
ENTITY_MAPPING <<express:Activity_arm.activity_item,activity_item>>;
EXTENSIBLE: TRUE;
...
END_ENTITY_MAPPING;
4.3.4 AIM element declaration
aim_element_decl = "AIM_ELEMENT" ":" ( express_link | string ) ";" newline ;
The AIM element declaration specifies the corresponding AIM (MIM) element for the ARM entity, providing a direct link between the ARM and MIM schemas.
When the AIM element is an entity or type defined in an EXPRESS schema, the value shall be an EXPRESS link. When the AIM element is a keyword (such as PATH, IDENTICAL MAPPING, or NO MAPPING EXTENSION PROVIDED) or a dotted attribute path (such as action.name), the value shall be a plain string.
Usage
Specify the AIM element as an EXPRESS link for entity references.
Specify the AIM element as a plain string for keywords and attribute paths.
ENTITY_MAPPING <<express:Activity_arm.Activity,Activity>>;
AIM_ELEMENT: "<<express:action_schema.executed_action,executed_action>>";
...
END_ENTITY_MAPPING;
ATTRIBUTE_MAPPING name;
ASSERTION_TO: "name";
AIM_ELEMENT: "action.name";
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING chosen_method;
ASSERTION_TO: "<<express:Activity_method_arm.Activity_method,Activity_method>>";
AIM_ELEMENT: "PATH";
REFPATH: {
executed_action
executed_action <= action
action.chosen_method -> action_method
action_method
};
END_ATTRIBUTE_MAPPING;
4.3.5 EXPRESS reference declaration
express_ref_decl = "EXPRESS_REF" ":" "[" [ string { "," string } ] "]" ";" newline ;The EXPRESS reference declaration lists EXPRESS references related to the mapping, used to link the mapping to specific parts of the EXPRESS schemas or other relevant documentation.
Usage
Provide a comma-separated list of references enclosed in square brackets.
Use an empty list “[]” if there are no references.
ENTITY_MAPPING <<express:Activity_arm.Activity,Activity>>;
EXPRESS_REF: ["action_schema", "management_resources_schema"];
...
END_ENTITY_MAPPING;
4.3.6 Reference path declaration
4.3.6.1 General
The reference path syntax in EXPRESS-Q is based on the ISO 10303 Mapping Specification and is used within the REFPATH sections to define precise mappings between ARM and MIM elements. This syntax allows for complex relationships and constraints to be expressed concisely.
refpath_decl = "REFPATH" ":" "{" newline
refpath_content
"}" ";" newline ;The reference path declaration defines the detailed mapping between ARM and MIM elements using the reference path syntax described earlier.
Usage
Begin with REFPATH: { and end with };.
Each line in the content describes a step in the mapping path.
Use indentation to indicate nested structures.
Use symbols like <=, =>, -> to indicate relationships between entities and attributes.
ENTITY_MAPPING <<express:Activity_arm.Activity,Activity>>;
REFPATH: {
executed_action <= action
action.chosen_method -> action_method
};
...
END_ENTITY_MAPPING;
4.3.6.2 Symbols and meaning
The reference path syntax uses several symbols to express relationships and constraints. These symbols are derived from the ISO 10303 Mapping Specification:
- []
Enclosed section constrains multiple MIM elements or sections of the reference path required to satisfy an information requirement.
- ()
Enclosed section constrains multiple MIM elements or sections of the reference path identified as alternatives within the mapping.
- {}
Enclosed section constrains the reference path to satisfy an information requirement.
- <>
Enclosed section constrains one or more required reference paths.
- ||
Enclosed section constrains the supertype entity.
- ->
The attribute whose name precedes the symbol references the entity or select type whose name follows the symbol.
- <-
The entity or select type whose name precedes the symbol is referenced by the entity attribute whose name follows the symbol.
- [i]
The attribute whose name precedes the symbol is an aggregate; any element of that aggregate is referred to.
- [n]
The attribute whose name precedes the symbol is an ordered aggregate; member n of that aggregate is referred to.
- =>
The entity whose name precedes the symbol is a supertype of the entity whose name follows the symbol.
- <=
The entity whose name precedes the symbol is a subtype of the entity whose name follows the symbol.
- =
The string, select, or enumeration type is constrained to a choice or value.
- \
The reference path expression continues on the next line.
- *
One or more instances of the relationship entity data type may be assembled in a relationship tree structure.
- --
The text following is a comment or introduces a clause reference.
- *>
The select or enumeration type whose name precedes the symbol is extended into the select or enumeration type whose name follows the symbol.
- <*
The select or enumeration type whose name precedes the symbol is an extension of the select or enumeration type whose name follows the symbol.
- !{}
Section enclosed by {} indicates a negative constraint placed on the mapping.
4.3.6.3 Usage and examples
The reference path syntax is used to define precise mappings between ARM and MIM elements. Here are some examples demonstrating various aspects of the syntax:
EXAMPLE 1 — Simple attribute mapping
REFPATH: {
product.id -> id
}EXAMPLE 2 — Subtype relationship
REFPATH: {
mechanical_context <= product_context
}EXAMPLE 3 — Complex mapping with alternatives and constraints
REFPATH: {
shape_representation <= representation
{representation.items[i] -> representation_item
representation_item =>
(geometric_representation_item
[geometric_representation_item.dim = 3] |
mapped_item)
}
}EXAMPLE 4 — Select type extension
REFPATH: {
person_and_organization_select *> organization
}EXAMPLE 5 — Negative constraint
REFPATH: {
product_definition_formation
!{product_definition_formation.make_or_buy = bought_item}
}4.3.6.4 Validation rules for reference paths
When validating reference paths, the following rules should be applied:
All referenced entities and attributes shall exist in the corresponding ARM or MIM schema.
The relationships between entities (supertype, subtype, attribute reference) shall be consistent with the schema definitions.
Constraints shall be syntactically correct and use only attributes or functions that are valid for the constrained entity.
Select type extensions shall be consistent with the schema definitions.
Aggregate references (using [i] or [n]) shall be applied only to attributes defined as aggregates in the schema.
Alternative mappings (using parentheses) shall all be valid according to the schema.
Negative constraints shall be logically consistent with the rest of the mapping and the schema definitions.
The overall structure of the reference path shall form a valid path through the schema, connecting the source ARM entity to the target MIM entity or attribute.
4.3.7 Alternative mapping declaration
alt_map_decl = "ALT_MAP" ":" "[" [ string { "," string } ] "]" ";" newline ;The alternative mapping declaration specifies alternative mappings, allowing for flexibility in cases where multiple valid mappings exist.
Usage
Provide a comma-separated list of alternative mappings enclosed in square brackets.
Use an empty list “[]” if there are no alternative mappings.
ENTITY_MAPPING GeometricRepresentation;
ALT_MAP: ["shape_representation", "tessellated_shape_representation"];
...
END_ENTITY_MAPPING;
4.3.8 Attribute mapping
attribute_mapping = "ATTRIBUTE_MAPPING" attribute_name ";" newline
"ASSERTION_TO" ":" ( express_link | string ) ";" newline
[ aim_element_decl ]
[ express_ref_decl ]
[ refpath_decl ]
"END_ATTRIBUTE_MAPPING" ";" newline ;
An attribute mapping defines how an individual attribute of an ARM entity corresponds to elements in the MIM schema.
The ASSERTION_TO value shall be an EXPRESS link when the attribute refers to an entity data type or a SELECT type, and a plain string otherwise.
Usage
Begin with “ATTRIBUTE_MAPPING” followed by the attribute name.
Specify the ASSERTION_TO value as an EXPRESS link or plain string.
Optionally include AIM_ELEMENT, EXPRESS_REF, and REFPATH declarations.
End with “END_ATTRIBUTE_MAPPING”.
ENTITY_MAPPING <<express:Activity_arm.Activity,Activity>>;
ATTRIBUTE_MAPPING chosen_method;
ASSERTION_TO: "<<express:Activity_method_arm.Activity_method,Activity_method>>";
AIM_ELEMENT: "PATH";
REFPATH: {
executed_action
executed_action <= action
action.chosen_method -> action_method
action_method
};
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
ATTRIBUTE_MAPPING name;
ASSERTION_TO: "name";
AIM_ELEMENT: "action.name";
REFPATH: {
executed_action
executed_action <= action
action.name
};
END_ATTRIBUTE_MAPPING;
5 Validation rules
5.1 General
Validation of EXPRESS-Q files is crucial to ensure the correctness and consistency of mappings between ARM and MIM schemas. The following rules should be applied when validating EXPRESS-Q files.
5.2 EXPRESS link validation
Each EXPRESS link shall conform to the syntax display_name.
The schema_name shall identify a valid EXPRESS schema accessible to the mapping.
The element_name shall identify an entity, type, or attribute defined in or imported into the referenced schema.
The display_name shall match the element_name.
5.3 Entity mapping validation
Each ENTITY_MAPPING shall correspond to an entity or type defined in the ARM schema. When the entity name is an EXPRESS link, the referenced entity shall exist in the referenced ARM schema.
The AIM_ELEMENT specified shall exist in the MIM schema or be a recognized keyword (PATH, IDENTICAL MAPPING, NO MAPPING EXTENSION PROVIDED, `/SUPERTYPE(…)/ `, /SUBTYPE(...)/). When the AIM element is an EXPRESS link, the referenced entity shall exist in the referenced MIM or resource schema.
All EXPRESS_REF entries shall refer to valid EXPRESS schemas.
The REFPATH shall form a valid path from the ARM entity to the specified AIM_ELEMENT.
If ALT_MAP is specified, all alternative mappings shall be valid MIM entities.
5.4 Attribute mapping validation
Each ATTRIBUTE_MAPPING shall correspond to an attribute of the ARM entity being mapped.
The ASSERTION_TO value shall be a valid type or entity in the ARM or MIM schema, as appropriate. When the value is an EXPRESS link, the referenced entity shall exist in the referenced schema.
If specified, the AIM_ELEMENT shall exist in the MIM schema or be a recognized keyword or dotted attribute path.
The REFPATH for an attribute shall form a valid path from the ARM attribute to the specified MIM element.
5.5 Reference path validation
All entities and attributes referenced in the REFPATH shall exist in either the ARM or MIM schema, as appropriate.
Relationships between entities (e.g., subtype, supertype) shall be consistent with the schema definitions.
Constraints specified in the REFPATH shall use valid attributes or functions for the entities they constrain.
SELECT type extensions shall be consistent with the schema definitions.
Aggregate references (using [i] or [n]) shall only be applied to attributes defined as aggregates in the schema.
5.6 Overall consistency
The complete set of mappings shall cover all entities and attributes in the ARM schema.
There should be no conflicting mappings (e.g., two different mappings for the same ARM entity or attribute).
The overall set of mappings should form a consistent and complete transformation from the ARM to the MIM schema.
6 Implementation guidelines
6.1 General
When implementing an EXPRESS-Q parser and validator, consider the following guidelines.
6.2 Parsing
Implement a lexical analyzer to tokenize the EXPRESS-Q input.
Develop a parser based on the EBNF grammar provided in this specification.
Create an abstract syntax tree (AST) or similar internal representation of the parsed EXPRESS-Q file.
6.3 Schema loading
Implement an EXPRESS schema parser or use an existing library to load and interpret ARM and MIM schemas.
Create internal representations of the schemas that allow for efficient querying of entities, attributes, and relationships.
6.4 Validation
Implement validation checks based on the rules outlined in the “Validation rules” section.
Perform two-pass validation:
First pass: Check syntax and basic semantic rules (e.g., entity and attribute existence).
Second pass: Validate complex semantic rules (e.g., consistency of reference paths).
Provide clear and informative error messages for validation failures.
6.5 Reference path interpretation
Implement a separate parser for the reference path syntax.
Develop algorithms to traverse reference paths within the context of the loaded schemas.
Implement functions to evaluate constraints specified in reference paths.
6.6 Performance considerations
Use efficient data structures (e.g., hash tables) for quick lookups of schema elements.
Implement caching mechanisms for frequently accessed schema information.
Consider parallel processing for validating multiple entity or attribute mappings simultaneously.
6.7 Extensibility
Design the implementation to be extensible, allowing for future enhancements to the EXPRESS-Q language.
Use modular design to separate concerns (e.g., parsing, schema handling, validation).
6.8 Integration
Provide APIs or interfaces for integrating the EXPRESS-Q parser and validator into larger systems or workflows.
Consider implementing export functionality to generate reports or machine-readable representations of the validation results.
7 Use cases and examples
7.1 General
This section provides examples of how EXPRESS-Q can be used in various scenarios related to STEP application protocols.
7.2 Use case 1: Mapping a module with cross-schema references
In this example, we demonstrate how EXPRESS-Q maps the Activity module, where the ARM entity Activity references Activity_method from a different module. EXPRESS links enable cross-document reference resolution in the published documentation.
ENTITY_MAPPING <<express:Activity_arm.Activity,Activity>>;
AIM_ELEMENT: "<<express:action_schema.executed_action,executed_action>>";
EXPRESS_REF: ["action_schema"];
REFPATH: {
executed_action <= action
};
ATTRIBUTE_MAPPING id;
ASSERTION_TO: "id";
AIM_ELEMENT: "id_attribute.attribute_value";
REFPATH: {
executed_action
executed_action <= action
action <- id_attribute.identified_item
id_attribute.attribute_value
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING name;
ASSERTION_TO: "name";
AIM_ELEMENT: "action.name";
REFPATH: {
executed_action
executed_action <= action
action.name
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING description;
ASSERTION_TO: "description";
AIM_ELEMENT: "action.description";
REFPATH: {
executed_action
executed_action <= action
action.description
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING chosen_method;
ASSERTION_TO: "<<express:Activity_method_arm.Activity_method,Activity_method>>";
AIM_ELEMENT: "PATH";
REFPATH: {
executed_action
executed_action <= action
action.chosen_method -> action_method
action_method
};
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
ENTITY_MAPPING <<express:Activity_arm.Activity_relationship,Activity_relationship>>;
AIM_ELEMENT: "<<express:action_schema.action_relationship,action_relationship>>";
ATTRIBUTE_MAPPING name;
ASSERTION_TO: "name";
AIM_ELEMENT: "action_relationship.name";
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING description;
ASSERTION_TO: "description";
AIM_ELEMENT: "action_relationship.description";
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING related_activity;
ASSERTION_TO: "<<express:Activity_arm.Activity,Activity>>";
AIM_ELEMENT: "PATH";
REFPATH: {
action_relationship
action_relationship.related_action -> action
action => executed_action
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING relating_activity;
ASSERTION_TO: "<<express:Activity_arm.Activity,Activity>>";
AIM_ELEMENT: "PATH";
REFPATH: {
action_relationship
action_relationship.relating_action -> action
action => executed_action
};
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
This example demonstrates how EXPRESS links in the entity name, AIM element, and ASSERTION_TO fields enable the published document to generate cross-references to other modules and resource schemas.
7.3 Use case 2: Mapping with alternative representations
This example shows how EXPRESS-Q can handle cases where an ARM entity might be mapped to different MIM representations based on certain conditions.
ENTITY_MAPPING GeometricRepresentation;
ALT_MAP: ["shape_representation", "tessellated_shape_representation"];
REFPATH: {
(shape_representation <= representation
[representation.context_of_items->geometric_representation_context]) |
(tessellated_shape_representation <= representation
[representation.context_of_items->geometric_representation_context])
};
ATTRIBUTE_MAPPING items;
ASSERTION_TO: "SET OF geometric_representation_item";
REFPATH: {
representation.items[i] -> geometric_representation_item
};
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
This example demonstrates how EXPRESS-Q can handle alternative mappings for a single ARM entity. The GeometricRepresentation entity can be mapped to either a shape_representation or a tessellated_shape_representation in the MIM schema, depending on the specific requirements of the application.
8 Summary
EXPRESS-Q provides a powerful and flexible language for defining mappings between ARM and MIM schemas in the context of STEP application protocols. By offering a standardized way to express these mappings, EXPRESS-Q facilitates more robust and reliable data exchange in complex engineering and manufacturing environments.
Key features of EXPRESS-Q include:
A syntax that is familiar to users of EXPRESS, reducing the learning curve.
The ability to define detailed mappings between ARM and MIM entities and attributes.
Support for complex reference paths, allowing for navigation through intricate schema relationships.
Mechanisms for specifying constraints and alternative mappings.
Clear separation of entity and attribute mappings for improved readability and maintainability.
The validation rules and implementation guidelines provided in this specification aim to ensure consistent interpretation and implementation of EXPRESS-Q across different tools and systems.
9 Future considerations
As the use of EXPRESS-Q grows and evolves, several areas may be considered for future enhancements:
9.1 Extended constraint language
Future versions of EXPRESS-Q might benefit from a more expressive constraint language, allowing for more complex conditions and transformations to be specified within mappings.
9.2 Integration with other standards
Consideration should be given to how EXPRESS-Q can be integrated with other relevant standards and technologies, such as ontology languages or model transformation frameworks.
9.3 Tool support
Development of standardized libraries and tools for parsing, validating, and processing EXPRESS-Q files would greatly facilitate its adoption and use.
9.4 Reverse mapping capabilities
Future versions might include capabilities for defining bi-directional mappings, allowing for the generation of ARM instances from MIM data.
9.5 Performance optimizations
As EXPRESS-Q is used with increasingly large and complex schemas, performance optimizations in both the language design and implementation guidelines may become necessary.
Annex A
(informative)
Complete EXPRESS-Q file example
This annex provides a complete example of an EXPRESS-Q file for the Activity module, demonstrating EXPRESS links for cross-schema references.
-- EXPRESS-Q file for the Activity module (ISO 10303-1047)
ENTITY_MAPPING <<express:Activity_arm.Activity,Activity>>;
EXTENSIBLE: FALSE;
AIM_ELEMENT: "<<express:action_schema.executed_action,executed_action>>";
EXPRESS_REF: ["action_schema", "basic_attribute_schema"];
REFPATH: {
executed_action <= action
};
ATTRIBUTE_MAPPING id;
ASSERTION_TO: "id";
AIM_ELEMENT: "id_attribute.attribute_value";
REFPATH: {
executed_action
executed_action <= action
action <- id_attribute.identified_item
id_attribute.attribute_value
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING name;
ASSERTION_TO: "name";
AIM_ELEMENT: "action.name";
REFPATH: {
executed_action
executed_action <= action
action.name
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING description;
ASSERTION_TO: "description";
AIM_ELEMENT: "action.description";
REFPATH: {
executed_action
executed_action <= action
action.description
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING chosen_method;
ASSERTION_TO: "<<express:Activity_method_arm.Activity_method,Activity_method>>";
AIM_ELEMENT: "PATH";
REFPATH: {
executed_action
executed_action <= action
action.chosen_method -> action_method
action_method
};
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
ENTITY_MAPPING <<express:Activity_arm.Activity_relationship,Activity_relationship>>;
EXTENSIBLE: FALSE;
AIM_ELEMENT: "<<express:action_schema.action_relationship,action_relationship>>";
ATTRIBUTE_MAPPING name;
ASSERTION_TO: "name";
AIM_ELEMENT: "action_relationship.name";
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING description;
ASSERTION_TO: "description";
AIM_ELEMENT: "action_relationship.description";
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING related_activity;
ASSERTION_TO: "<<express:Activity_arm.Activity,Activity>>";
AIM_ELEMENT: "PATH";
REFPATH: {
action_relationship
action_relationship.related_action -> action
action => executed_action
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING relating_activity;
ASSERTION_TO: "<<express:Activity_arm.Activity,Activity>>";
AIM_ELEMENT: "PATH";
REFPATH: {
action_relationship
action_relationship.relating_action -> action
action => executed_action
};
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
ENTITY_MAPPING <<express:Activity_arm.Activity_status,Activity_status>>;
EXTENSIBLE: FALSE;
AIM_ELEMENT: "<<express:action_schema.action_status,action_status>>";
ATTRIBUTE_MAPPING assigned_activity;
ASSERTION_TO: "<<express:Activity_arm.Activity,Activity>>";
AIM_ELEMENT: "PATH";
REFPATH: {
action_status
action_status.assigned_action -> executed_action
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING status;
ASSERTION_TO: "status";
AIM_ELEMENT: "action_status.status";
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
ENTITY_MAPPING <<express:Activity_arm.Applied_activity_assignment,Applied_activity_assignment>>;
EXTENSIBLE: FALSE;
AIM_ELEMENT: "<<express:Activity_mim.applied_action_assignment,applied_action_assignment>>";
EXPRESS_REF: ["management_resources_schema"];
ATTRIBUTE_MAPPING assigned_activity;
ASSERTION_TO: "<<express:Activity_arm.Activity,Activity>>";
AIM_ELEMENT: "PATH";
REFPATH: {
applied_action_assignment
applied_action_assignment <= action_assignment
action_assignment
action_assignment.assigned_action -> action
action => executed_action
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING items;
ASSERTION_TO: "<<express:Activity_arm.activity_item,activity_item>>";
AIM_ELEMENT: "PATH";
REFPATH: {
applied_action_assignment
applied_action_assignment.items[i] -> action_items
};
END_ATTRIBUTE_MAPPING;
ATTRIBUTE_MAPPING role;
ASSERTION_TO: "role";
AIM_ELEMENT: "object_role.name";
REFPATH: {
applied_action_assignment
applied_action_assignment <= action_assignment
action_assignment.role -> object_role
object_role.name
};
END_ATTRIBUTE_MAPPING;
END_ENTITY_MAPPING;
This example demonstrates the complete mapping for the Activity module, including:
EXPRESS links for entity names (Activity)
EXPRESS links for AIM elements (executed_action)
EXPRESS links for cross-module assertions (Activity_method)
Plain string AIM elements for attribute paths (action.name) and keywords (PATH)
Reference paths with subtype, supertype, and attribute relationships
Annex B
(normative)
YAML serialization
B.1 General
This annex defines the YAML serialization format for EXPRESS-Q mapping specifications. Each application module’s mapping specification is stored as a YAML file named mapping.yaml in the module’s schema directory.
The YAML serialization provides a machine-readable representation of the EXPRESS-Q constructs defined in this specification, suitable for automated processing, validation, and document generation.
B.2 File structure
A mapping YAML file has a single top-level key ae (application elements) containing an ordered list of entity mappings.
---
ae:
- entity: ...
aimelt: ...
aa:
- attribute: ...
...
B.3 Schema
The following describes each field in the YAML serialization.
B.3.1 Entity mapping
Each entry in the ae list represents an entity mapping and contains the following fields:
- entity
(required) The ARM entity being mapped. The value shall be an EXPRESS link identifying the ARM schema and entity: Entity_name.
For backward compatibility, a plain entity name is also accepted.- aimelt
(required) The corresponding MIM element. The value shall be one of:
An EXPRESS link for entity references: entity_name
A plain string for keywords: PATH, IDENTICAL MAPPING, NO MAPPING EXTENSION PROVIDED
A plain string for /SUPERTYPE(...)/, /SUBTYPE(...)/, or /MAPPING_OF(...)/ constructs
A plain string for dotted attribute paths: entity.attribute
A parenthesized or bracketed list of the above for multiple MIM elements
- extensible
(optional) Boolean indicating whether the mapping is extensible.
- alt_map
(optional) List of alternative MIM entity names.
- original_module
(optional) Name of the module from which this mapping originates (for inherited mappings).
- description
(optional) Additional descriptive text.
- aa
(optional) List of attribute mappings for this entity.
B.3.2 Attribute mapping
Each entry in the aa list represents an attribute mapping and contains the following fields:
- attribute
(required) The ARM attribute name being mapped.
- aimelt
(optional) The corresponding MIM element. At the attribute level, the value is a plain string (not an EXPRESS link). Typical values include:
A dotted attribute path: action.name
The keyword PATH (when assertion_to is present)
The keyword IDENTICAL MAPPING
- assertion_to
(optional) The target entity or type that this attribute refers to. When present, the value shall be an EXPRESS link: Entity_name.
The special value * indicates any type.
For backward compatibility, a plain entity name is also accepted.- refpath
(optional) The reference path specifying the detailed mapping between ARM and MIM elements.
B.3.3 Reference path
The refpath field contains an object with a single key:
- content
(required) A multi-line string containing the reference path expression using the syntax defined in [reference-path-declaration]. Lines are separated by newline characters. The YAML block scalar |- is used to preserve line breaks and strip the trailing newline.
refpath:
content: |-
executed_action
executed_action <= action
action.chosen_method -> action_method
action_method
B.4 EXPRESS link format
EXPRESS links in YAML values use the following syntax:
<<express:schema_name.element_name,display_name>>
Where:
- schema_name
The name of the EXPRESS schema containing the element.
- element_name
The name of the entity, type, or function within the schema.
- display_name
The name displayed in rendered documentation (shall match element_name).
The schema name encodes the origin of the referenced element, eliminating the need for a separate source field.
B.5 Correspondence to EBNF constructs
The following table shows the correspondence between EBNF constructs and YAML keys:
| EBNF construct | YAML key | Notes |
|---|---|---|
| ENTITY_MAPPING entity_ref | ae[].entity | EXPRESS link or plain name |
| aim_element_decl | ae[].aimelt or ae[].aa[].aimelt | Entity-level: EXPRESS link or string; attribute-level: plain string |
| ASSERTION_TO | ae[].aa[].assertion_to | EXPRESS link or plain string |
| extensible_decl | ae[].extensible | Boolean |
| alt_map_decl | ae[].alt_map | List of strings |
| refpath_decl | ae[].aa[].refpath.content | Multi-line string |
| express_ref_decl | Not serialized | Schema references are encoded in EXPRESS links |
| source_decl | Not serialized | Source is derived from EXPRESS links |
B.6 Complete example
The following shows the complete YAML serialization of the Activity module mapping specification:
---
ae:
- entity: <<express:Activity_arm.Activity,Activity>>
aimelt: <<express:action_schema.executed_action,executed_action>>
aa:
- attribute: name
aimelt: action.name
refpath:
content: |-
executed_action
executed_action <= action
action.name
- attribute: description
aimelt: action.description
refpath:
content: |-
executed_action
executed_action <= action
action.description
- attribute: chosen_method
assertion_to: <<express:Activity_method_arm.Activity_method,Activity_method>>
aimelt: PATH
refpath:
content: |-
executed_action
executed_action <= action
action.chosen_method -> action_method
action_method
- attribute: id
aimelt: id_attribute.attribute_value
refpath:
content: |-
executed_action
executed_action <= action
action <- id_attribute.identified_item
id_attribute.attribute_value
- entity: <<express:Activity_arm.Activity_relationship,Activity_relationship>>
aimelt: <<express:action_schema.action_relationship,action_relationship>>
aa:
- attribute: description
aimelt: action_relationship.description
- attribute: name
aimelt: action_relationship.name
- attribute: related_activity
assertion_to: <<express:Activity_arm.Activity,Activity>>
aimelt: PATH
refpath:
content: |-
action_relationship
action_relationship.related_action -> action
action => executed_action
- attribute: relating_activity
assertion_to: <<express:Activity_arm.Activity,Activity>>
aimelt: PATH
refpath:
content: |-
action_relationship
action_relationship.relating_action -> action
action => executed_action
- entity: <<express:Activity_arm.Activity_status,Activity_status>>
aimelt: <<express:action_schema.action_status,action_status>>
aa:
- attribute: assigned_activity
assertion_to: <<express:Activity_arm.Activity,Activity>>
aimelt: PATH
refpath:
content: |-
action_status
action_status.assigned_action -> executed_action
- attribute: status
aimelt: action_status.status
- entity: <<express:Activity_arm.Applied_activity_assignment,Applied_activity_assignment>>
aimelt: <<express:Activity_mim.applied_action_assignment,applied_action_assignment>>
aa:
- attribute: assigned_activity
assertion_to: <<express:Activity_arm.Activity,Activity>>
aimelt: PATH
refpath:
content: |-
applied_action_assignment
applied_action_assignment <= action_assignment
action_assignment
action_assignment.assigned_action -> action
action => executed_action
- attribute: items
assertion_to: <<express:Activity_arm.activity_item,activity_item>>
aimelt: PATH
refpath:
content: |-
applied_action_assignment
applied_action_assignment.items[i] -> action_items
- attribute: role
aimelt: object_role.name
refpath:
content: |-
applied_action_assignment
applied_action_assignment <= action_assignment
action_assignment.role -> object_role
object_role.name
Bibliography
[1] ISO 10303-21:2016, Industrial automation systems and integration — Product data representation and exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure