avoid collections in EXPRESS TYPEs

[pipauwel]

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?

[aothms]

Can't we make them ENTITIES with attributes?

Note the implication here, that then

#1 = IfcSite(...., (1,2,3))

becomes

#1 = IfcSite(...., #2) 
#2 = IfcCompoundPlaneAngleMeasure(1,2,3)

This is bad new for IfcIndexedPolyCurve. By using TYPE IfcArcIndex the entire curve can be defined in one entity instance as opposed to spread out over multiple references when using ENTITY.

Whether we need IfcIndexedPolyCurve is a 2nd question, as it can only cover a subset of geometries that IfcCompositeCurve can describe, although the latter a bit less efficiently.

[TLiebich]

lets come back to the original question. What is the source of the issue:

to have defined types being aggregates? or to have attributes with a defined data type being an aggregate?

in the above case, one other solution could be:

ENTITY IfcSite
 SUBTYPE OF (IfcSpatialStructureElement);
  RefLatitude : OPTIONAL LIST[3:4] OF INTEGER;
  RefLongitude : OPTIONAL LIST[3:4] OF INTEGER;
  RefElevation : OPTIONAL IfcLengthMeasure;
  LandTitleNumber : OPTIONAL IfcLabel;
  SiteAddress : OPTIONAL IfcPostalAddress;
END_ENTITY;

[TLiebich]

regarding IfcIndexedPolyCurve - this is strange - the entity had been introduced on IFC4.0.1 as a request to simplify IFC (same as the overall theme for this thread) and now removing it again for simplification?

At that time, we did an extensive survey - see here: IFC4_Add1_IndexedPolyCurve_Definition.pdf

[berlotti]

Principle agreement on this. Find solutions case-by-case.

PS: keep IfcIndexedPolyCurve, but on two (or three) star conformance level