buildingSMART / buildingSMART/NextGen-IFC

avoid collections in EXPRESS TYPEs

Open
#22 4 comments 3 reactions 0 assignees View on GitHub
Dominant language
TeX
Stars
64
Forks
4
PR merge metrics
No merged PRs in 30d

Description

There are very few TYPEs equivalent to a collection (LIST, ARRAY, SET). Examples are:

```
TYPE IfcArcIndex = LIST [3:3] OF IfcPositiveInteger;
END_TYPE;

TYPE IfcComplexNumber = ARRAY [1:2] OF REAL;
END_TYPE;

TYPE IfcCompoundPlaneAngleMeasure = LIST [3:4] OF INTEGER;
WHERE
MinutesInRange : ABS(SELF[2]) < 60;
SecondsInRange : ABS(SELF[3]) < 60;
MicrosecondsInRange : (SIZEOF(SELF) = 3) OR (ABS(SELF[4]) < 1000000);
ConsistentSign : ((SELF[1] >= 0) AND (SELF[2] >= 0) AND (SELF[3] >= 0) AND ((SIZEOF(SELF) = 3) OR (SELF[4] >= 0)))
OR
((SELF[1] <= 0) AND (SELF[2] <= 0) AND (SELF[3] <= 0) AND ((SIZEOF(SELF) = 3) OR (SELF[4] <= 0)));
END_TYPE;
```

I suggest to encode these differently. As a result, we can likely more easily translate all TYPEs to known datatypes in other languages (e.g. xsd:dateTime, xsd:integer, etc.), rather than having to encode exceptions for these particular cases. Can't we make them ENTITIES with attributes?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.