Open jakob-beetz opened 4 years ago
+1 seems like an easy fix.
If possible, we should resort to SETs (no order), instead of LISTs. Not possible in this case, so that should be IfcMaterialLayerList
and IfcPolygonalFaceList
.
while I agree on the issue, I would question the cost / benefit ratio here. Yes, a name "IfcMaterialLayerList" is actually more precise, but the cost to change the class = all instance names is high (this entity exists since end of the 1990's in IFC with probably millions of instances in IFC files).
I would opt for not changing, but clearly stating the anomaly in the documentation.
or alternatively:
Explicit is better than implicit.
, There should be one - and preferably only one - obvious way to do it.
to cite one former BDFL)LIST OF IfcMaterialLayer
).There are other points to consider in attribute names, such as OffsetFromReferenceLine
(a) it's probably a surface at least in case of slabs (b) it doesn't need to be a line, can be an arbitrary curve in case of curved walls. Point is, if we intend to be precise about terminology we need to review a lot.
Meets the requirements of https://github.com/buildingSMART/NextGen-IFC/wiki/Ten-principles-for-a-future-IFC
What was the conclusion on this one? It wasn't clear from reading the comments.
Tiny, and maybe discussed before within MSG but I have witnessed people being
infuriatedslightly irritated about this: Currently, we havewith
LIST
as a collection type (proper, because order of layers is very relevant) but Set in the namingsimilar for
I thought this was an inheritance from ISO 10303-42, but there we only have a (meaningful)