[0] Parsing EXPRESS Schemas with Python — A Field Exercise on ISO/TS 10303-442 MIM_LF

This paper presents a methodology for the automated extraction and structural analysis of **ISO 10303 (STEP)** schemas, with a specific focus on the **Modular Integrated Model (MIM) Layered Framework (ISO/TS 10303-442)**. As model-based enterprises transition toward agentic digital twins, the ability to programmatically reason over the underlying EXPRESS-defined (ISO 10303-11) information architecture becomes a critical bottleneck. I propose a Python-based parsing pipeline that treats normative EXPRESS files as immutable remote resources, transforming flat schema blocks into rich, hierarchical data structures. By analyzing entity-root scarcity, inheritance depth, and SELECT type proliferation within the **AP242** ecosystem, this study provides a foundational "instrumentation layer" for downstream LLM context injection and cross-standard gap analysis. This work represents an interpretive implementation of the STEP architecture, intended to bridge the gap between static normative documentation and dynamic, machine-actionable engineering informatics.

The **ISO 10303** standard, colloquially known as **STEP**, represents perhaps the most structurally ambitious effort in the history of standardized information. Its goal is a total, computationally processable representation of a product's entire lifecycle—independent of vendor, CAD system, or engineering discipline. At the heart of this ambition is **EXPRESS**, a data modeling language defined in **Part 11** that predates modern schema formats yet exceeds them in semantic depth. Navigating the STEP corpus, particularly the **MIM_LF (ISO/TS 10303-442)** schema used in **AP242**, presents a significant technical challenge. These schemas are not merely lists of attributes; they are complex directed acyclic graphs (DAGs) defined by inheritance, global rules, and procedural functions.

### Scope, Technical Disclosure & Intellectual Property This paper serves as a position piece on the **automated parsing and interpretive synthesis** of these schemas. It is important to note the following boundaries: * **Interpretive Implementation:** The code and data structures (`EntityDef`, `TypeDef`) described herein are original interpretations of the EXPRESS grammar. * **Normative References:** This study references the **ISO/TS 10303-442** schema as a "ground truth" resource. In compliance with intellectual property standards, this paper does not redistribute the copyrighted text of the ISO standards; rather, it provides the logic for interacting with these files via official technical repositories (such as the **MBX-IF** and **ISO standards server**). * **Interpretive Logic:** All parsing logic, data structures (`EntityDef`, `TypeDef`), and analytical summaries are the original work of the author, representing an implementation-level interpretation of the standard's grammar. * **Research Intent:** The primary objective is to enable "agentic reasoning"—allowing digital twin systems to validate data and generate context based on the formal semantics encoded within the standard. * **Distribution:** This article does not redistribute the standard's text. The provided code fetches normative files directly from official ISO or MBX-IF repositories for the purpose of interoperability analysis. * **Source Materials:** The schemas referenced (e.g., `mim_lf.exp`) are the intellectual property of the International Organization for Standardization (ISO).

ISO 10303 (STEP — Standard for the Exchange of Product model data) is one of the most structurally ambitious standards ever published. Its ambition is total: a single, computationally processable representation of product data across its entire lifecycle, independent of any system, vendor, or discipline. Part 11 of the standard defines EXPRESS — a declarative schema language purpose-built for this task. EXPRESS predates most modern schema languages and shares conceptual DNA with Pascal and object-oriented type systems, but operates at a higher semantic level. It describes not just structure but constraints, derivations, and formal invariants. An EXPRESS schema is simultaneously a data model, a type system, and a partial axiom set. The standard is partitioned into Application Protocols (APs), each targeting a domain: AP203 for configuration-controlled design, AP214 for automotive, AP242 for managed model-based 3D engineering. Each AP publishes an Application Interpreted Model (AIM) — a large monolithic EXPRESS schema — alongside its normative text. The modular restructuring introduced in the 2010s changed this. ISO 10303-4xx defines Application Modules (AMs): small, composable EXPRESS schemas with well-defined interfaces. An AP is now assembled from a library of modules rather than written as one giant file. The Modular Integrated Model (MIM) for an AP is the result of integrating all required modules into a single schema — the functional equivalent of the old AIM, but traceable to its module origins. ISO/TS 10303-442 is the Modular Integrated Manufacturing (MIM) Layered Framework. The `mim_lf.exp` schema is literally the most comprehensive single EXPRESS file in the STEP corpus: it integrates the complete set of Application Modules needed for AP242 ed.2 and represents the current state of the STEP information architecture for model-based enterprise. Parsing this file is not an academic exercise. For any agentic digital twin system that needs to reason over STEP data — validating STEP Part 21 file instances, generating schema-grounded LLM context, or performing cross-standard gap analysis between ISO 10303 and ISO 16739 (IFC) — this schema is the ground truth.

The MBX-IF (Model-Based Experience Implementor Forum), hosted at `https://www.mbx-if.org/home/mbx/resources/express-schemas/`, maintains the canonical distribution point for EXPRESS schemas across the STEP and related families. It is the practitioner's first stop — not ISO's official website, which distributes schemas as normative attachments to purchased standards documents. The MBX-IF page provides direct download links for current editions of schemas including: - MIM_LF (ISO/TS 10303-442) — the subject of this exercise - IFC EXPRESS schemas (ISO 16739) — for cross-standard work - SMRL (Shape Representation Module Reference Library) - Individual Application Module schemas The URL we will use is the normative Ed.7 MIM_LF schema from the ISO standards server itself, which MBX-IF references: https://standards.iso.org/iso/ts/10303/-442/ed-7/tech/express/mim_lf.exp This file is authoritative. It is large — expect several megabytes — and it is the integration of hundreds of modules, each contributing entities, types, rules, and functions into a single flat SCHEMA...END_SCHEMA block.

Before parsing, you need to know exactly what you are parsing. EXPRESS (ISO 10303-11) defines a small but precise grammar. The constructs relevant to schema analysis are: **SCHEMA block** — the top-level container. Every EXPRESS file has exactly one. SCHEMA mim_lf; USE FROM (, , ...); REFERENCE FROM (...); ...declarations... END_SCHEMA; The USE FROM and REFERENCE FROM statements are the module interface. In a MIM schema, these are resolved — all referenced entities are physically present — so we can ignore them for parsing purposes. **ENTITY** — the primary structural unit. Entities support single-root multiple inheritance via SUBTYPE/SUPERTYPE constraints. ENTITY [ABSTRACT] [SUPERTYPE OF ()] [SUBTYPE OF (, , ...)]; : [OPTIONAL] ; ... [DERIVE : := ; ...] [INVERSE : [SET|BAG] [] OF FOR ; ...] [UNIQUE : , ; ...] [WHERE : ; ...] END_ENTITY; The DERIVE section defines computed attributes — attributes whose values are not stored but calculated from other attributes, potentially traversing the entity graph. This is semantically richer than most schema languages and relevant for digital twin inference. The WHERE section defines formal domain rules — invariants that every valid instance must satisfy. These are the schema's type constraints expressed as boolean functions. For agentic validation, these rules are gold: they encode the semantics the schema author considered essential enough to formalise. **TYPE** — named type aliases and composite types. Four forms are critical: TYPE identifier = STRING; -- alias (renamed primitive) END_TYPE; TYPE measure_value = SELECT ( -- discriminated union length_measure, mass_measure, plane_angle_measure); END_TYPE; TYPE component_type = ENUMERATION OF -- closed enumeration (assembly, part, document); END_TYPE; TYPE list_of_string = LIST [1:?] OF STRING; -- aggregation END_TYPE; **Aggregation types** appear inline as attribute types too: components : SET [1:?] OF part_definition; coordinates : ARRAY [1:3] OF REAL; items : LIST [0:?] OF UNIQUE action_item; The cardinality syntax `[N:M]` where `?` means unbounded is a source of parsing complexity — especially when types are nested. **RULE** — global invariants that span multiple entities. Not covered in this exercise but present in the MIM_LF schema. They define cross-entity consistency constraints. **FUNCTION / PROCEDURE** — EXPRESS supports procedural logic for computing derived values and performing side-effects. Functions appear in DERIVE expressions and WHERE rules. We will extract their names but not parse their bodies.

This parser is deliberately not a full PEG or ANTLR grammar. That would be correct engineering for a production compiler — but our goal is structured extraction, not validation. The EXPRESS grammar is regular enough that a well-designed regex scanner, combined with section-aware string splitting, covers the 95% case for the entities and types we care about. The pipeline has five stages: 1. **Acquisition** — HTTP fetch with local cache. STEP files use Latin-1 encoding per ISO 10303-21; the schema files follow the same convention. 2. **Normalisation** — Strip comments (block `(* *)` and line `--`), which can contain spurious keywords that fool naive pattern matchers. 3. **Schema extraction** — Isolate the SCHEMA...END_SCHEMA block and extract the schema name. In MIM_LF this gives us the module identity. 4. **Declaration scanning** — Regex scan for ENTITY and TYPE blocks. Because these blocks do not nest in EXPRESS, a non-overlapping DOTALL regex is sufficient and fast even on megabyte-scale inputs. 5. **Block parsing** — For each extracted block, parse the header (ABSTRACT, SUPERTYPE OF, SUBTYPE OF), split the body into sections (explicit, DERIVE, INVERSE, UNIQUE, WHERE), and parse each section into typed dataclass instances. The output is a list of `EntityDef` and `TypeDef` dataclasses, which feed directly into hierarchy analysis, JSON serialisation for LLM context, or graph construction for downstream agentic reasoning.

The implementation requires only the Python standard library. No third-party packages. ```python import re import json import urllib.request from dataclasses import dataclass, field from pathlib import Path from collections import defaultdict from typing import Optional # region CONSTANTS MBXIF_RESOURCES = "https://www.mbx-if.org/home/mbx/resources/express-schemas/" SCHEMA_URL = "https://standards.iso.org/iso/ts/10303/-442/ed-7/tech/express/mim_lf.exp" CACHE_DIR = Path("src/var/data/schemas") # endregion ```

Dataclasses give us typed, inspectable objects without the overhead of ORM-style frameworks. The `section` field on `Attribute` distinguishes explicit attributes from derived and inverse ones — a distinction that matters for digital twin reasoning, because derived attributes represent computable knowledge while inverse attributes encode the reverse traversal of relationships. ```python # region DATA STRUCTURES @dataclass class Attribute: """ An attribute on an EXPRESS ENTITY. Attributes ---------- name : str Attribute identifier as declared in the schema. type_expr : str Raw type expression string, e.g. 'SET [1:?] OF product_definition'. optional : bool True if preceded by OPTIONAL keyword. section : str Source section: 'explicit' | 'derived' | 'inverse'. """ name: str type_expr: str optional: bool = False section: str = "explicit" @dataclass class WhereRule: """ A WHERE domain rule from an ENTITY or TYPE declaration. Attributes ---------- label : str Rule identifier, e.g. 'WR1', 'UR1'. expression : str Boolean expression text (not parsed further here). """ label: str expression: str @dataclass class EntityDef: """ Parsed representation of an EXPRESS ENTITY declaration. Attributes ---------- name : str Entity name. abstract : bool True if the entity carries the ABSTRACT keyword. supertypes : list[str] Names from SUBTYPE OF (...) — direct parents in the hierarchy. supertype_constraint : str | None The ONEOF(...) or AND expression from SUPERTYPE OF, if present. This encodes the partitioning constraint on the entity's subtypes. attributes : list[Attribute] All attributes across explicit, derived, and inverse sections. where_rules : list[WhereRule] Formal domain invariants declared in the WHERE section. """ name: str abstract: bool = False supertypes: list[str] = field(default_factory=list) supertype_constraint: Optional[str] = None attributes: list[Attribute] = field(default_factory=list) where_rules: list[WhereRule] = field(default_factory=list) @dataclass class TypeDef: """ Parsed representation of an EXPRESS TYPE declaration. Attributes ---------- name : str Type name. kind : str One of: 'alias' | 'enumeration' | 'select' | 'aggregate'. base : str Underlying content — primitive type, comma-separated enum values, SELECT members, or aggregation expression. where_rules : list[WhereRule] Formal constraints on alias types (e.g., string length restrictions). """ name: str kind: str base: str where_rules: list[WhereRule] = field(default_factory=list) # endregion ```

The fetch function treats the schema URL as an immutable remote resource. After the first download it reads from disk. STEP-family files historically use Latin-1 (ISO 8859-1) encoding, not UTF-8 — the schema body is 7-bit ASCII in practice, but the encoding declaration matters for robustness. ```python # region ACQUISITION def fetch_schema(url: str, cache_dir: Path) -> str: """ Download EXPRESS schema with local caching. STEP physical files (ISO 10303-21) mandate ISO 8859-1 encoding. EXPRESS schema files (.exp) follow the same convention. Parameters ---------- url : str Full URL to the .exp file. cache_dir : Path Directory to cache the raw file. Returns ------- str Schema text decoded from Latin-1. """ filename = url.split("/")[-1] cache_path = cache_dir / filename if cache_path.exists(): print(f"[cache hit] {cache_path}") return cache_path.read_text(encoding="latin-1") print(f"[fetch] {url}") req = urllib.request.Request( url, headers={"User-Agent": "EXPRESS-Schema-Parser/1.0 (research)"}, ) with urllib.request.urlopen(req, timeout=60) as resp: raw = resp.read() text = raw.decode("latin-1") cache_dir.mkdir(parents=True, exist_ok=True) cache_path.write_text(text, encoding="utf-8") print(f"[saved] {cache_path} ({len(text):,} chars)") return text # endregion ```

Comment stripping is stage zero of parsing. The MIM_LF schema is heavily commented — entity-level annotations, source module tracability markers, and STEP editorial notes all appear in block comments. The regex must be non-greedy on block comments and strip line-comments without disturbing string literals. EXPRESS block comments do not nest (ISO 10303-11 §7.1.5.2), which simplifies the regex considerably. ```python # region NORMALISATION def strip_comments(text: str) -> str: """ Remove EXPRESS comment forms from schema text. Express defines two comment forms (ISO 10303-11 §7.1.5): - Block: (* ... *) — non-nestable - Line: -- to end of line Parameters ---------- text : str Raw schema text. Returns ------- str Schema text with all comments replaced by single spaces. """ # Block comments — non-greedy, DOTALL for multiline text = re.sub(r'\(\*.*?\*\)', ' ', text, flags=re.DOTALL) # Line comments — to end of line text = re.sub(r'--[^\n]*', '', text) return text def extract_schema_block(text: str) -> tuple[str, str]: """ Isolate the primary SCHEMA...END_SCHEMA block. Parameters ---------- text : str Normalised schema text. Returns ------- tuple[str, str] (schema_name, schema_body) where schema_body is everything between the opening semicolon and END_SCHEMA;. Raises ------ ValueError If no valid SCHEMA block is found. """ m = re.search( r'\bSCHEMA\s+(\w+)\s*;(.*?)\bEND_SCHEMA\s*;', text, re.DOTALL | re.IGNORECASE, ) if not m: raise ValueError("No SCHEMA...END_SCHEMA block found in text") return m.group(1), m.group(2) # endregion ```

Entity parsing is the heart of the exercise. The key insight is that each ENTITY block has a clear two-part structure: a **header** (everything before the first semicolon) and a **body** (the attribute and constraint sections). The sections in the body are delimited by reserved words — DERIVE, INVERSE, UNIQUE, WHERE — which never appear as attribute names. The attribute line format `name : [OPTIONAL] type_expr` is regular enough for a simple split, but the type expression can be arbitrarily complex: components : SET [1:?] OF UNIQUE (action_item); mapping : LIST [0:?] OF LIST [1:?] OF REAL; ref : representation_or_representation_reference; We capture the full type expression as a string and defer deeper type parsing to a separate stage (not implemented here, but straightforward to add). ```python # region ENTITY PARSING def _split_entity_sections(body: str) -> dict[str, str]: """ Partition entity body into named sections. EXPRESS entities partition their body with keyword markers. This function slices the body string at those markers. Parameters ---------- body : str Entity body text (after the header semicolon, before END_ENTITY). Returns ------- dict[str, str] Keys: 'explicit', 'DERIVE', 'INVERSE', 'UNIQUE', 'WHERE'. Values: raw text of each section. """ section_re = re.compile( r'\b(DERIVE|INVERSE|UNIQUE|WHERE)\b', re.IGNORECASE ) parts: dict[str, str] = {} current_key = "explicit" current_start = 0 for m in section_re.finditer(body): parts[current_key] = body[current_start : m.start()].strip() current_key = m.group(1).upper() current_start = m.end() parts[current_key] = body[current_start:].strip() return parts def _parse_attribute_line( line: str, section: str = "explicit" ) -> Optional[Attribute]: """ Parse a single attribute declaration line. Handles: explicit form ( : [OPTIONAL] ) and derived form ( : := ) — for derived, pass only the left side of ':='. Parameters ---------- line : str Raw attribute text, semicolons stripped. section : str Source section tag. Returns ------- Attribute | None Parsed attribute, or None if the line is not a valid declaration. """ line = line.strip().rstrip(';') if ':' not in line: return None colon_pos = line.index(':') name = line[:colon_pos].strip() # Attribute names are simple identifiers if not re.match(r'^\w+$', name): return None type_expr = line[colon_pos + 1:].strip() optional = bool(re.match(r'OPTIONAL\b', type_expr, re.IGNORECASE)) if optional: type_expr = re.sub(r'^OPTIONAL\s+', '', type_expr, flags=re.IGNORECASE) return Attribute(name=name, type_expr=type_expr, optional=optional, section=section) def parse_entity(name: str, raw_block: str) -> EntityDef: """ Parse a complete ENTITY block into an EntityDef. Parses the full EXPRESS entity grammar including: - ABSTRACT and SUPERTYPE OF constraints - SUBTYPE OF inheritance declarations - Explicit, derived, and inverse attribute sections - WHERE domain rules Parameters ---------- name : str Entity name (already extracted by the scanner). raw_block : str Complete text from ENTITY ... END_ENTITY; Returns ------- EntityDef Structured representation of the entity. """ # Strip outer ENTITY/END_ENTITY wrappers body = re.sub(r'^ENTITY\s+\w+', '', raw_block, flags=re.IGNORECASE).strip() body = re.sub(r'END_ENTITY\s*;?\s*$', '', body, flags=re.IGNORECASE).strip() # Split header (before first ';') from attribute sections first_semi = body.find(';') header = body[:first_semi].strip() if first_semi != -1 else body remainder = body[first_semi + 1:].strip() if first_semi != -1 else '' # --- Header parsing --- is_abstract = bool(re.search(r'\bABSTRACT\b', header, re.IGNORECASE)) # SUBTYPE OF (, ...) — direct supertype list subtype_m = re.search( r'SUBTYPE\s+OF\s*\(([^)]+)\)', header, re.IGNORECASE ) supertypes = ( [s.strip() for s in subtype_m.group(1).split(',')] if subtype_m else [] ) # SUPERTYPE OF () — partitioning constraint on subtypes # The constraint is typically ONEOF(...) or AND(ONEOF(...), ...) supertype_m = re.search( r'SUPERTYPE\s+OF\s*\((.+)', header, re.IGNORECASE | re.DOTALL ) supertype_constraint = ( supertype_m.group(1).strip().rstrip(')').strip() if supertype_m else None ) # --- Body section parsing --- sections = _split_entity_sections(remainder) attributes: list[Attribute] = [] # Explicit attributes — simple : [OPTIONAL] for stmt in re.split(r';', sections.get('explicit', '')): attr = _parse_attribute_line(stmt.strip(), 'explicit') if attr: attributes.append(attr) # Derived attributes — : := for stmt in re.split(r';', sections.get('DERIVE', '')): stmt = stmt.strip() if ':=' in stmt: attr_decl = stmt.split(':=', 1)[0] attr = _parse_attribute_line(attr_decl, 'derived') if attr: attributes.append(attr) # Inverse attributes — same format as explicit but carry set/bag cardinality for stmt in re.split(r';', sections.get('INVERSE', '')): attr = _parse_attribute_line(stmt.strip(), 'inverse') if attr: attributes.append(attr) # WHERE rules — : where_rules: list[WhereRule] = [] for stmt in re.split(r';', sections.get('WHERE', '')): stmt = stmt.strip() if ':' in stmt: colon = stmt.index(':') label = stmt[:colon].strip() expr = stmt[colon + 1:].strip() if re.match(r'^\w+$', label) and expr: where_rules.append(WhereRule(label=label, expression=expr)) return EntityDef( name=name, abstract=is_abstract, supertypes=supertypes, supertype_constraint=supertype_constraint, attributes=attributes, where_rules=where_rules, ) def extract_entities(schema_body: str) -> list[EntityDef]: """ Scan schema body and extract all ENTITY...END_ENTITY blocks. ENTITY blocks do not nest in EXPRESS, so a non-overlapping DOTALL regex scan is sufficient and O(n) in schema size. Parameters ---------- schema_body : str Normalised schema body (comments stripped, USE/REFERENCE present). Returns ------- list[EntityDef] Parsed entities in declaration order. """ pattern = re.compile( r'\bENTITY\s+(\w+)(.*?)END_ENTITY\s*;', re.DOTALL | re.IGNORECASE, ) entities: list[EntityDef] = [] for m in pattern.finditer(schema_body): try: entity = parse_entity(m.group(1), m.group(0)) entities.append(entity) except Exception as exc: print(f"[warn] parse failure on entity '{m.group(1)}': {exc}") return entities # endregion ```

Type parsing is structurally simpler than entity parsing. The four flavours have distinct opening tokens: `ENUMERATION OF`, `SELECT`, an aggregation keyword (`LIST`/`SET`/`BAG`/`ARRAY`), or a direct type expression (alias). The only complication is that SELECT and ENUMERATION bodies can span multiple lines with embedded comments — hence the importance of normalising before scanning. SELECT types in STEP schemas are particularly information-dense. The `measure_value` SELECT, for instance, unifies twenty-odd measurement types under one name, encoding the representational polymorphism that physical quantities require. ```python # region TYPE PARSING def extract_types(schema_body: str) -> list[TypeDef]: """ Extract all TYPE...END_TYPE declarations from schema body. Parameters ---------- schema_body : str Normalised schema body. Returns ------- list[TypeDef] Parsed types with kind classification and WHERE rules. """ pattern = re.compile( r'\bTYPE\s+(\w+)\s*=\s*(.*?)\s*END_TYPE\s*;', re.DOTALL | re.IGNORECASE, ) types: list[TypeDef] = [] for m in pattern.finditer(schema_body): name = m.group(1) definition = m.group(2).strip() if re.match(r'ENUMERATION\s+OF', definition, re.IGNORECASE): kind = 'enumeration' items_m = re.search(r'\(([^)]+)\)', definition, re.DOTALL) base = items_m.group(1).strip() if items_m else definition elif re.match(r'SELECT', definition, re.IGNORECASE): kind = 'select' # SELECT bodies may nest parentheses for extended selects items_m = re.search(r'\((.+)\)', definition, re.DOTALL) base = items_m.group(1).strip() if items_m else definition elif re.match(r'\b(LIST|SET|BAG|ARRAY)\b', definition, re.IGNORECASE): kind = 'aggregate' base = definition.split(';')[0].strip() else: kind = 'alias' base = definition.split(';')[0].strip() # WHERE rules in TYPE declarations (common on alias types) where_rules: list[WhereRule] = [] where_m = re.search( r'\bWHERE\b(.*)', m.group(0), re.DOTALL | re.IGNORECASE ) if where_m: for rule_text in re.split(r';', where_m.group(1)): rule_text = rule_text.strip() if ':' in rule_text: label, expr = rule_text.split(':', 1) label = label.strip() if re.match(r'^\w+$', label): where_rules.append( WhereRule(label=label, expression=expr.strip()) ) types.append( TypeDef(name=name, kind=kind, base=base, where_rules=where_rules) ) return types # endregion ```

The hierarchy analysis functions transform the flat list of `EntityDef` objects into a graph structure. `build_hierarchy` produces a parent→children adjacency map from the SUBTYPE OF declarations, giving us the tree in its natural downward direction. `compute_hierarchy_depth` computes the maximum depth of the subtree rooted at each entity. In the MIM_LF schema, the hierarchy depth of root entities like `representation_item` or `founded_item` is substantial — tracing these chains reveals the expressive layering that STEP uses to model physical and conceptual structures without redundancy. `find_roots` identifies entities with no SUBTYPE OF declaration. These are the hierarchy root points. In a large modular schema, most roots correspond to abstract foundation entities defined in the STEP integrated resource schemas (Parts 41–50). ```python # region HIERARCHY ANALYSIS def build_hierarchy(entities: list[EntityDef]) -> dict[str, list[str]]: """ Build parent → direct-children adjacency map. Parameters ---------- entities : list[EntityDef] All parsed entities. Returns ------- dict[str, list[str]] Maps each entity name to a list of its direct subtypes. """ children: dict[str, list[str]] = defaultdict(list) for entity in entities: for parent in entity.supertypes: children[parent].append(entity.name) return dict(children) def compute_hierarchy_depth( entity_name: str, children_map: dict[str, list[str]], _memo: dict | None = None, ) -> int: """ Compute maximum depth of the subtree rooted at entity_name. Memoised recursive descent. Returns 0 for leaf entities. Parameters ---------- entity_name : str Root of the subtree. children_map : dict[str, list[str]] Parent → children adjacency map from build_hierarchy. _memo : dict | None Internal memoisation cache; pass None on initial call. Returns ------- int Maximum leaf depth in the subtree. """ if _memo is None: _memo = {} if entity_name in _memo: return _memo[entity_name] kids = children_map.get(entity_name, []) if not kids: depth = 0 else: depth = 1 + max( compute_hierarchy_depth(k, children_map, _memo) for k in kids ) _memo[entity_name] = depth return depth def find_roots(entities: list[EntityDef]) -> list[str]: """ Return entity names that have no SUBTYPE OF declaration. These are the topmost nodes in the inheritance forest — typically abstract foundation types from the STEP integrated resources. Parameters ---------- entities : list[EntityDef] All parsed entities. Returns ------- list[str] Sorted list of root entity names. """ all_names = {e.name for e in entities} has_parent = {e.name for e in entities if e.supertypes} return sorted(all_names - has_parent) # endregion ```

The summary function aggregates everything into a serialisable report. Key metrics for the MIM_LF schema include entity and type counts, the distribution of type kinds (SELECT types are particularly numerous in STEP), the entity with the most attributes, and the entities with the deepest and widest subtrees. This summary is immediately usable as a system prompt context block for an LLM that needs to reason about the schema — or as a dashboard data source for a schema observatory. ```python # region REPORTING def summarize( schema_name: str, entities: list[EntityDef], types: list[TypeDef], ) -> dict: """ Produce a structured analysis summary of parsed schema artefacts. Parameters ---------- schema_name : str Extracted schema identifier. entities : list[EntityDef] All parsed entities. types : list[TypeDef] All parsed types. Returns ------- dict JSON-serialisable analysis report. """ children_map = build_hierarchy(entities) depth_memo: dict[str, int] = {} abstract_count = sum(1 for e in entities if e.abstract) constrained_count = sum(1 for e in entities if e.supertype_constraint) with_where = sum(1 for e in entities if e.where_rules) attr_counts = {e.name: len(e.attributes) for e in entities} max_attr_count = max(attr_counts.values(), default=0) max_attr_entity = next( (n for n, c in attr_counts.items() if c == max_attr_count), None ) # Deepest subtree root depths = { e.name: compute_hierarchy_depth(e.name, children_map, depth_memo) for e in entities } deepest_name = max(depths, key=depths.get) if depths else None type_kinds: dict[str, int] = defaultdict(int) for t in types: type_kinds[t.kind] += 1 select_types = [t for t in types if t.kind == 'select'] widest_select = max( select_types, key=lambda t: t.base.count(','), default=None, ) top_branching = sorted( entities, key=lambda e: len(children_map.get(e.name, [])), reverse=True, )[:10] return { "schema": schema_name, "entities": { "total": len(entities), "abstract": abstract_count, "with_supertype_constraint": constrained_count, "with_where_rules": with_where, "most_attributes": { "entity": max_attr_entity, "count": max_attr_count, }, }, "types": { "total": len(types), "by_kind": dict(type_kinds), "widest_select": { "type": widest_select.name if widest_select else None, "member_count": widest_select.base.count(',') + 1 if widest_select else 0, }, }, "hierarchy": { "roots": find_roots(entities), "deepest_subtree": { "root": deepest_name, "depth": depths.get(deepest_name, 0) if deepest_name else 0, }, "top_10_by_direct_subtypes": [ { "entity": e.name, "direct_subtypes": len(children_map.get(e.name, [])), "abstract": e.abstract, } for e in top_branching ], }, } # endregion ```

The pipeline function wires the stages together. It is idempotent: re-running on a cached schema produces identical output. The JSON report is written alongside the cached schema file for downstream consumption. ```python # region PIPELINE def run( url: str = SCHEMA_URL, cache_dir: Path = CACHE_DIR, output_path: Path | None = None, ) -> dict: """ Full pipeline: fetch → normalise → parse → analyse → persist. Parameters ---------- url : str EXPRESS schema URL (defaults to MIM_LF Ed.7). cache_dir : Path Local cache and output directory. output_path : Path | None JSON report output path. Defaults to cache_dir/_analysis.json. Returns ------- dict Structured analysis report (also written to output_path). """ raw = fetch_schema(url, cache_dir) clean = strip_comments(raw) schema_name, body = extract_schema_block(clean) print(f"[schema] {schema_name} ({len(body):,} chars)") entities = extract_entities(body) print(f"[entities] {len(entities):,} found") types = extract_types(body) print(f"[types] {len(types):,} found") report = summarize(schema_name, entities, types) resolved_output = output_path or ( cache_dir / f"{schema_name}_analysis.json" ) resolved_output.parent.mkdir(parents=True, exist_ok=True) resolved_output.write_text( json.dumps(report, indent=2), encoding="utf-8" ) print(f"[output] {resolved_output}") return report if __name__ == "__main__": import pprint pprint.pp(run()) # endregion ```

The MIM_LF schema is large by any measure. When you run the pipeline against the Ed.7 file you will encounter an entity count in the low thousands and a type count of similar order. This scale reflects the scope of ISO/TS 10303-442: it integrates all Application Modules needed to represent managed model-based engineering information across the full product lifecycle — geometry, topology, materials, kinematics, process planning, configuration management, documents, and more. Several structural observations are immediately useful for downstream work. **Root entity scarcity.** Despite thousands of entities, the number of hierarchy roots is small — typically under twenty. Most roots are foundation types from the STEP integrated resources: `founded_item`, `representation_item`, `action`, `product`, `document`. These are the conceptual atoms of the STEP information model. Every domain-specific entity, from `machining_feature` to `kinematic_pair`, traces back through a chain of SUBTYPE OF declarations to one of these roots. **Hierarchy depth.** Some subtrees are deep — depths exceeding ten levels are present. This reflects the progressive specialisation pattern that STEP uses: a general concept at the root becomes increasingly specific at the leaves. Parsing this depth is essential for any reasoning system that needs to navigate the schema, because attribute inheritance is implicit — a subtype's complete information set is the union of all its ancestors' attributes, traversed up to the root. **ABSTRACT prevalence.** A significant fraction of entities carry the ABSTRACT keyword. These can never be directly instantiated in a STEP Part 21 file — they exist purely to carry shared attributes and establish the conceptual hierarchy. For instance, `shape_representation` is abstract; instances are always of a concrete subtype like `advanced_brep_shape_representation`. For a validation engine, correctly identifying abstract entities is critical to generating accurate instantiation constraints. **SELECT proliferation.** The type analysis reveals that SELECT types outnumber enumerations. SELECTs are STEP's discriminated union mechanism and are used pervasively to represent representational alternatives: a `measure_value` can be any of many measurement types; a `product_definition_or_reference` collapses two semantically related types into one attribute slot. SELECT membership counts are a proxy for semantic complexity — a SELECT with thirty members represents a design decision with thirty implementation paths, each of which a reasoning engine must potentially traverse. **WHERE rule density.** Entities with WHERE rules are where the schema's semantic depth lives. A WHERE rule like `WR1: SIZEOF(QUERY(item <* SELF.items | NOT ('AP242_MANAGED_MODEL_BASED_3D_ENGINEERING...' IN TYPEOF(item)))) = 0` is not just a constraint — it is a formal specification of valid composition. Extracting and classifying WHERE rules is the first step toward building a schema-driven constraint solver for digital twin validation pipelines.

The `EntityDef` list produced by this parser is the input layer for several high-value analyses. **Entity relationship graph.** The SUBTYPE/SUPERTYPE data maps directly to a directed acyclic graph. Using `networkx` (or a pure-Python adjacency structure), you can compute ancestor chains, identify the common supertype of any two entities (critical for polymorphic query planning), and detect isolated subtrees that indicate module boundaries. Visualised, the STEP entity graph is one of the most structurally rich graphs in the engineering informatics world. **Schema-to-LLM context injection.** Large language models operating over STEP data need schema grounding. Rather than injecting the full schema text (prohibitively large), inject targeted entity definitions: the entity being discussed, its direct supertype chain, its attributes with types, and its WHERE rules. This parser produces exactly the structured data needed to generate those targeted context blocks programmatically. **Cross-standard gap analysis.** IFC (ISO 16739, `IFC4.exp`) and STEP both model building and construction artefacts — but with different entity hierarchies, different attribute names, and different constraint philosophies. Parsing both schemas with this infrastructure enables systematic attribute-level comparison: which STEP entities have no IFC equivalent, where are the semantic mismatches, and where is information lost in cross-schema exchange. This is the foundation layer for OpenBIM/STEP convergence work. **STEP Part 21 file validation.** A STEP physical file (`.stp`, `.step`) lists entity instances line by line in a DATA section. Each instance references an entity type by name and provides attribute values positionally. The parsed schema gives you: 1. The ordered attribute list for each entity (determining positional mapping) 2. The type of each attribute (enabling value validation) 3. The WHERE rules (enabling constraint checking) 4. The ABSTRACT flags (enabling instantiation validity checks) A validation engine built on this parser can process a STEP Part 21 file against the schema without any external library — pure Python, pure standard library, full ISO 10303 conformance checking. **Agentic schema evolution tracking.** The MIM_LF schema changes between editions. Diffing the parsed output of Ed.6 and Ed.7 — entities added, entities removed, attributes changed, WHERE rules modified — gives a machine-readable changelog that no human-authored release note fully captures. For long-lived digital twin programmes operating on multi-edition STEP data, this parser is the instrumentation layer for schema governance.

The AECO and Real Estate industries have historically remained laggards in the digital revolution, often treating data as a byproduct of the design process rather than its most valuable asset. While other sectors transitioned to real-time, data-driven decision-making decades ago, the built environment remains largely fragmented, trapped in static PDFs and "dark data" silos. This research, and the development of the EXPRESS parsing infrastructure presented here, is a deliberate move toward a new, sovereign discipline: **Built Environment Intelligence (BEI)**. Unlike traditional Business Intelligence (BI), which often reports on historical financial metrics, BEI is rooted in the deep, formal semantics of the physical world. By programmatically deconstructing the **ISO 10303** architecture, we move beyond simple data exchange and toward **Agentic Digital Twins**.

### The SME Perspective: Self-Exploration as Innovation The methodology described in this paper is the result of an intentional self-exploration—a process of "learning by building" to master the complex DNA of the STEP and IFC standards. This positioning is critical for the future of the industry. As we move away from manual coordination and toward autonomous agents that can reason over a building's lifecycle, the role of the Subject Matter Expert must evolve. The expert of tomorrow will not just "know" the standard; they will build the automated interpreters that allow AI to "understand" the standard. This parser is more than a technical utility; it is a foundational component of a **Reasoning Engine** that bridges the gap between the rigid, normative past of ISO standards and the fluid, agentic future of the Built Environment. Through the lens of BEI, we do not merely see a schema of entities and types. We see the formal logic required to automate the world's largest asset class.

| EXPRESS Construct | Parser Output | Key Fields | |-----------------------|---------------------|-----------------------------------------| | ENTITY | EntityDef | name, abstract, supertypes, attributes | | SUBTYPE OF (...) | EntityDef.supertypes| list[str] of parent names | | SUPERTYPE OF (ONEOF) | EntityDef.supertype_constraint | raw constraint text | | Explicit attribute | Attribute(section='explicit') | name, type_expr, optional | | DERIVE attribute | Attribute(section='derived') | name, type_expr | | INVERSE attribute | Attribute(section='inverse') | name, type_expr | | WHERE rule | WhereRule | label, expression | | TYPE = STRING (alias) | TypeDef(kind='alias') | base = 'STRING' | | TYPE = SELECT (...) | TypeDef(kind='select') | base = comma-sep members | | TYPE = ENUM OF (...) | TypeDef(kind='enumeration') | base = comma-sep values | | TYPE = LIST ... OF | TypeDef(kind='aggregate') | base = full agg expr |

| Schema | Standard | URL | |-------------------|-----------------------|------------------------------------------------------------------------------| | MIM_LF Ed.7 | ISO/TS 10303-442 Ed.7 | https://standards.iso.org/iso/ts/10303/-442/ed-7/tech/express/mim_lf.exp | | IFC4 EXPRESS | ISO 16739-1:2018 | https://standards.buildingsmart.org/IFC/RELEASE/IFC4/FINAL/EXPRESS/IFC4.exp | | MBX-IF Hub | — | https://www.mbx-if.org/home/mbx/resources/express-schemas/ |