expressions and variables

Description of the proposal:

Expressions and variables are useful for parameterizable designs (e.g. late fixing of storey height).
Additionally, functional and logical dependencies can be represented by expressions.
In electrical engineering we use this as well for repeated analysis (simulation) with different electrical properties of a component.
See: https://www.analog.com/en/technical-articles/ltspice-using-the-step-command-to-perform-repeated-analysis.html

The common way to mark expressions is to embrace the expression by curly brackets.
e.g.: { 70% * STOREY_HEIGHT }
where STOREY_HEIGHT is a variable to be substituted later by value or another expression

Describe how it contributes to the objectives set in https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC:
technology independence due to common mechanism used for expressions

What do we win:
exchange of parameterized designs

What do we loose
nothing

Schema impact:
none

Instance model impact:
?

Backwards compatible:
yes

Automatic migration possible:
yes

Additional implications:
unknown

Start by reading the proposal and the linked Towards a technology-independent IFC objectives page, then review how the IFC schema and instance model represent values and dependencies. Compare the suggested curly-bracket expressions and variable substitution with the cited repeated-analysis use case. Done means a decided expression and variable mechanism with its instance-model implications, compatibility, and migration behavior documented.

Written by the indexing model from the issue text.