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.
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.
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;onIfcBSplineSurfaceCoordList : LIST [1:?] OF LIST [2:2] OF IfcLengthMeasure;onIfcCartesianPointList2DCoordList : LIST [1:?] OF LIST [3:3] OF IfcLengthMeasure;onIfcCartesianPointList3DColourList : LIST [1:?] OF LIST [3:3] OF IfcNormalisedRatioMeasure;onIfcColourRgbListInnerCoordIndices : LIST [1:?] OF LIST [3:?] OF UNIQUE IfcPositiveInteger;onIfcIndexedPolygonalFaceWithVoidsTexCoordIndex : OPTIONAL LIST [1:?] OF LIST [3:3] OF IfcPositiveInteger;onIfcIndexedTriangleTextureMapWeightsData : LIST [2:?] OF LIST [2:?] OF IfcReal;onIfcRationalBSplineSurfaceWithKnotsInnerTexCoordIndices : LIST [1:?] OF LIST [3:?] OF UNIQUE IfcPositiveInteger;onIfcTextureCoordinateIndicesWithVoidsTexCoordsList : LIST [1:?] OF LIST [2:2] OF IfcParameterValue;onIfcTextureVertexListOPTIONAL LIST [1:?] OF LIST [3:3] OF IfcParameterValue;onIfcTriangulatedFaceSetCoordIndex : LIST [1:?] OF LIST [3:3] OF IfcPositiveInteger;onIfcTriangulatedFaceSetDespite IFC providing a deep and comprehensive type system, these nested LISTs seem to strip away semantic intent. Two concrete examples:
IfcCartesianPointentity, whose members areIfcLengthMeasure, we're instead redeclaring a similar definition asLIST [2:2] OF IfcLengthMeasureinIfcCartesianPointList2D. Why not defineIfcCartesianPointList2Din terms of aLIST OF [1:?] IfcCartesianPoint2D?IfcColourRgbentity, whose members areIfcNormalisedRatioMeasure, we're instead redeclaring a similar definition asLIST [3:3] OF IfcNormalisedRatioMeasure;inIfcColourRgbList. Why not defineIfcColourRgbListasLIST [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.