Removing LISTS of LISTS from schema

[devonsparks]

Description of the proposal:

There are several cases in IFC (11 specifically in IFC4x3 by my count) of schema attributes that declare LISTS of LISTS. Most of these relate to geometry and share a similar flavor:

• ControlPointsList : LIST [2:?] OF LIST [2:?] OF IfcCartesianPoint; on IfcBSplineSurface
• CoordList : LIST [1:?] OF LIST [2:2] OF IfcLengthMeasure; on IfcCartesianPointList2D
• CoordList : LIST [1:?] OF LIST [3:3] OF IfcLengthMeasure; on IfcCartesianPointList3D
• ColourList : LIST [1:?] OF LIST [3:3] OF IfcNormalisedRatioMeasure; on IfcColourRgbList
• InnerCoordIndices : LIST [1:?] OF LIST [3:?] OF UNIQUE IfcPositiveInteger; on IfcIndexedPolygonalFaceWithVoids
• TexCoordIndex : OPTIONAL LIST [1:?] OF LIST [3:3] OF IfcPositiveInteger; on IfcIndexedTriangleTextureMap
• WeightsData : LIST [2:?] OF LIST [2:?] OF IfcReal; on IfcRationalBSplineSurfaceWithKnots
• InnerTexCoordIndices : LIST [1:?] OF LIST [3:?] OF UNIQUE IfcPositiveInteger; on IfcTextureCoordinateIndicesWithVoids
• TexCoordsList : LIST [1:?] OF LIST [2:2] OF IfcParameterValue; on IfcTextureVertexList
• OPTIONAL LIST [1:?] OF LIST [3:3] OF IfcParameterValue; on IfcTriangulatedFaceSet
• CoordIndex : LIST [1:?] OF LIST [3:3] OF IfcPositiveInteger; on IfcTriangulatedFaceSet

Despite IFC providing a deep and comprehensive type system, these nested LISTs seem to strip away semantic intent. Two concrete examples:

• Despite IFC defining a dedicated IfcCartesianPoint entity, whose members are IfcLengthMeasure, we're instead redeclaring a similar definition as LIST [2:2] OF IfcLengthMeasure in IfcCartesianPointList2D. Why not define IfcCartesianPointList2D in terms of a LIST OF [1:?] IfcCartesianPoint2D?
• Despite IFC defining a dedicated IfcColourRgb entity, whose members are IfcNormalisedRatioMeasure, we're instead redeclaring a similar definition as LIST [3:3] OF IfcNormalisedRatioMeasure; in IfcColourRgbList. Why not define IfcColourRgbList as LIST [1:?] OF IfcColourRgb?

The other examples are similar, and removal of the nested lists increases model cohesion.

Describe how it contributes to the objectives (https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC):

By removing all occurrences of nested lists, all multi-valued attributes become single-level lists or sets, which simplifies encoding and transformation across technology backends.

Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one): change

What do we win: consistency, cohesion, simplified integration patterns.

What do we lose: Software vendors would need to update their processing code for these types. Increase in file size.

Schema impact: Likely introduction of several new TYPEs, and removal of all nested LISTS.

Instance model impact: All nested lists replaced with single-level lists or sets of ENTITY or TYPE instances.

Backwards compatible: No.

Automatic migration possible: Yes.

Additional implications:

Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.