Extend IfcOpenShell EXPRESS schema parser with support for where rules, functions and derived attributes

[aothms]

Outline

IfcOpenShell has a code generator that generates C++ code from the IFC schema defined in the EXPRESS language (wiki). This language allows for the definition of functions and rules that are currently not taken into account in the parsing process. These rules range from simple scalar checks like:

TYPE IfcPositiveLengthMeasure = IfcLengthMeasure;
 WHERE
    WR1 : SELF > 0.;
END_TYPE;

to complex turing complete functions to validate geometric constructs, like:

ENTITY IfcExtrudedAreaSolid
 SUPERTYPE OF (ONEOF
    (IfcExtrudedAreaSolidTapered))
 SUBTYPE OF (IfcSweptAreaSolid);
    ExtrudedDirection : IfcDirection;
    Depth : IfcPositiveLengthMeasure;
 WHERE
    ValidExtrusionDirection : IfcDotProduct(IfcRepresentationItem() || IfcGeometricRepresentationItem() || IfcDirection([0.0,0.0,1.0]), SELF.ExtrudedDirection) <> 0.0;
END_ENTITY;

FUNCTION IfcDotProduct
(Arg1, Arg2 : IfcDirection) 
    : REAL;
LOCAL
  Scalar : REAL;
  Vec1, Vec2 : IfcDirection;
  Ndim   : INTEGER;
END_LOCAL;

  IF NOT EXISTS (Arg1) OR NOT EXISTS (Arg2) THEN
    Scalar := ?;
  ELSE
    IF (Arg1.Dim <> Arg2.Dim) THEN
      Scalar := ?;
    ELSE
      BEGIN
        Vec1 := IfcNormalise(Arg1);
        Vec2 := IfcNormalise(Arg2);
        Ndim := Arg1.Dim;
        Scalar := 0.0;
        REPEAT i := 1 TO Ndim;
          Scalar := Scalar + Vec1.DirectionRatios[i]*Vec2.DirectionRatios[i];
        END_REPEAT;
      END;
    END_IF;
  END_IF;
  RETURN (Scalar);
END_FUNCTION;

This GSoC proposal suggests an initial parser for these rules and an implementation in the Python, C++ or Java programming language. Python is an excellent choice for this being quick to write and expressive, yet can offer it's application in STEPcode exp2py, FreeCAD, IfcOpenShell and BlenderBIM. C++ is the language in which the core of IfcOpenShell is written, so can also be used. Java has notable parsing frameworks such as ANTLR so are also allowed if preferred by the applicant.

Implementing support for these clauses serves several purposes: (a) The automated validation of IFC building models is a crucial aspect in enabling trust in information exchanges. The current practice is that often information from other project stakeholders is neglected because of a lack of trust in the validity. (b) At the same time though, the standardization organization behind IFC realizes that the EXPRESS language is out of style and more modern approaches exist to encode schema information. A flexible parser for EXPRESS where rules and functions might serve as a transpiler to encode the body of rules in different formats. (c) Lastly, domain extensions are currently being authored around IFC by domain experts and people from academia, giving them access to a parser and validator for EXPRESS rules will help them in defining their domain rules in the schema.

Details

The current version of the IfcOpenShell express code generator is available here https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.6.0/src/ifcopenshell-python/ifcopenshell/express It uses the pyparsing parser framework. The project participant may consider switching to a more modern library such as Lark given it's out of the box support for BNF or Parsec.py if a parser generator / functional programming approach matches the taste of the applicant. The IfcOpenShell project maintainers are definitely open to replacing the current code generator with an alternative developed as part of this proposal.

Expected Outcome

The ideal outcome would be a Python implementation of an EXPRESS rule parser with a good well-structured syntax tree. Depending on the preferences of the applicant one might choose to implement functionality to apply the rules to a population model (an actual file) in Python, preferably using the IfcOpenShell-python parser, or work on code generation to bring the validation to C++.

Future Possibilities

This project will focus on the rules in the IFC schemas. Given the use of the Python programming language it will be readily applicable in FreeCAD and BlenderBIM (which both rely on IfcOpenShell for IFC parsing). The aim is though for this to be applicable much wider in the future (such as other STEP schemas) and when a general approach is taken to rewrite one AST to another maybe also other programming languages.

Project Properties

Skills

Programming language: Python, C++, Java (or another language of choice if agreed by mentors)

Parser libraries

Compilers / code generation

Difficulty

High

Size

Medium (175h)

The applicant focusses on parsing and applying the parsed rules to a model it is expected to remain low-level functionality.

Long (350h)

The applicant delivers a tool of higher maturity that reports meaningful data to end users.

Additional Information

Potential mentor(s): Thomas Krijnen @aothms

Organization website: http://ifcopenshell.org/

Communication channels: https://sourceforge.net/p/ifcopenshell/discussion/

[plaes]

@aothms Can you add link to https://en.wikipedia.org/wiki/EXPRESS_(data_modeling_language)? This would give some extra background about EXPRESS is and its importance.

[brlcad]

STEPcode has a library for parsing EXPRESS files (libexpress, Part 11 files) implemented in C that could probably be extracted stand-alone without much difficulty (EXPRESS parsing one of the lowest libraries in STEPcode, if not the lowest). Some examples here. Sounds like it might be applicable?

[aothms]

@brlcad we're aware, 11y ago we evaluated and contributed to stepcode https://github.com/stepcode/stepcode/wiki/SCL-adoption-in-IfcOpenShell with the intention to adopt it.

For pragmatic reasons it went slight different. We had to write our own p21 parser (we needed more permissive parsing because of the rather poor state our industry was in back then). The IFC dialect of p28 had diverted quite a bit from the standard and stepcode didn't support p28. With rapid succession of IFC standard development, IFC2X3 IFC4 IFC4X1 X2 X3 and up to IFC4X4 soon, we also preferred a more modern C++ implementation to allow for schema agnostic code using C++ templates. But always in the back of our head that we would want to integrate with STEPcode to also offer compliant sdai based implementation.

We now have a reasonable p11 parser and code generator. But it still lack code generation for functions rules and derived attributes. The proposal is really about that specifically. Last time I checked I don't think that STEPcode offered support for that, (stepcode/stepcode#130). I will change back this topic title to the previous state but I will add a new one to integrate STEPcode #66

[brlcad]

Okay, sounds good. On the surface, I'd think even adapting STEPcode's P11 parser or even creating a new P28 parser wouldn't be terribly complicated... or entirely horrific given how most things are in 10303. Heh. I just wanted to make sure you were aware the library existed and you clearly are, so it's all good. Hopefully someone tackles it!

[aothms]

Express rules, functions, where clauses and derived attributes are now reasonably well supported in IfcOpenShell. So I'm closing this.