© ISO 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email:
Website: www.iso.org
Published in Switzerland
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.
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.
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.
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
IEC Electropedia: available at
query language for EXPRESS schemas, used to define mappings and constraints between ARM and MIM schemas
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.
The following EBNF (Extended Backus-Naur Form) grammar defines the syntax of EXPRESS-Q:
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.
This section describes the meaning and usage of each major construct in EXPRESS-Q.
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.
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.
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.
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”.
The extensible declaration specifies whether the entity mapping is extensible, corresponding to the extensibility of SELECT types in EXPRESS schemas.
Use “EXTENSIBLE: TRUE;” for extensible mappings.
Use “EXTENSIBLE: FALSE;” for non-extensible mappings.
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.
Specify the AIM element as an EXPRESS link for entity references.
Specify the AIM element as a plain string for keywords and attribute paths.
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.
Provide a comma-separated list of references enclosed in square brackets.
Use an empty list “[]” if there are no references.
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.
The reference path declaration defines the detailed mapping between ARM and MIM elements using the reference path syntax described earlier.
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.
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.
The attribute whose name precedes the symbol is an aggregate; any element of that aggregate is referred to.
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.
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:
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.
The alternative mapping declaration specifies alternative mappings, allowing for flexibility in cases where multiple valid mappings exist.
Provide a comma-separated list of alternative mappings enclosed in square brackets.
Use an empty list “[]” if there are no alternative mappings.
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.
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”.
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.
Each EXPRESS link shall conform to the syntax
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.
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.
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.
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.
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.
When implementing an EXPRESS-Q parser and validator, consider the following guidelines.
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.
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.
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.
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.
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.
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).
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.
This section provides examples of how EXPRESS-Q can be used in various scenarios related to STEP application protocols.
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.
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.
This example shows how EXPRESS-Q can handle cases where an ARM entity might be mapped to different MIM representations based on certain conditions.
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.
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.
As the use of EXPRESS-Q grows and evolves, several areas may be considered for future enhancements:
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.
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.
Development of standardized libraries and tools for parsing, validating, and processing EXPRESS-Q files would greatly facilitate its adoption and use.
Future versions might include capabilities for defining bi-directional mappings, allowing for the generation of ARM instances from MIM data.
As EXPRESS-Q is used with increasingly large and complex schemas, performance optimizations in both the language design and implementation guidelines may become necessary.
This annex provides a complete example of an EXPRESS-Q file for the Activity module, demonstrating EXPRESS links for cross-schema references.
This example demonstrates the complete mapping for the Activity module, including:
EXPRESS links for entity names (
EXPRESS links for AIM elements (
EXPRESS links for cross-module assertions (
Plain string AIM elements for attribute paths (action.name) and keywords (PATH)
Reference paths with subtype, supertype, and attribute relationships
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.
A mapping YAML file has a single top-level key ae (application elements) containing an ordered list of entity mappings.
The following describes each field in the YAML serialization.
Each entry in the ae list represents an entity mapping and contains the following fields:
(required) The ARM entity being mapped. The value shall be an EXPRESS link identifying the ARM schema and entity:
For backward compatibility, a plain entity name is also accepted.
(required) The corresponding MIM element. The value shall be one of:
An EXPRESS link for entity references:
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
(optional) Boolean indicating whether the mapping is extensible.
(optional) List of alternative MIM entity names.
(optional) Name of the module from which this mapping originates (for inherited mappings).
(optional) Additional descriptive text.
(optional) List of attribute mappings for this entity.
Each entry in the aa list represents an attribute mapping and contains the following fields:
(required) The ARM attribute name being mapped.
(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
(optional) The target entity or type that this attribute refers to. When present, the value shall be an EXPRESS link:
The special value * indicates any type.
For backward compatibility, a plain entity name is also accepted.
(optional) The reference path specifying the detailed mapping between ARM and MIM elements.
The refpath field contains an object with a single key:
(required) A multi-line string containing the reference path expression using the syntax defined in
EXPRESS links in YAML values use the following syntax:
Where:
The name of the EXPRESS schema containing the element.
The name of the entity, type, or function within the schema.
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.
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 |
The following shows the complete YAML serialization of the Activity module mapping specification:
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.
Cancelled and replaced by ISO/IEC 8824-1:2015.
Cancelled and replaced by ISO/IEC 10646:2012.