buildingSMART / buildingSMART/NextGen-IFC
avoid collections in EXPRESS TYPEs
- 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.