Not exactly affecting the schema, but does affect Pset definition templates, and definitely affects the users experience as it removes an important ambiguity that I've seen come up again and again. Basically the defined by type Name attribute and the Pset_*Common.Reference is a duplicate, seemingly as a fallback for software that doesn't implement IFC types. I propose to remove the duplication and stick to Name, which is the natural identification field people look for and has always been recommended in the past.
Description of the proposal:
Not exactly affecting the schema, but does affect Pset definition templates, and definitely affects the users experience as it removes an important ambiguity that I've seen come up again and again. Basically the defined by type
Nameattribute and thePset_*Common.Referenceis a duplicate, seemingly as a fallback for software that doesn't implement IFC types. I propose to remove the duplication and stick toName, which is the natural identification field people look for and has always been recommended in the past.More info: https://forums.buildingsmart.org/t/how-do-you-store-element-codes-in-ifc/884 More more info: https://standards.buildingsmart.org/documents/Implementation/IFC_Implementation_Agreements/CV-2x3-136.html
Describe how it contributes to the objectives (https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC):
Less complexity, as there is a clear rule of where data should be stored
Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one):
Remove
What do we win:
Less complexity
What do we lose
Compatibility with software that doesn't support type relationships
Schema impact:
Pset definition template removed
Instance model impact: ?
Backwards compatible:
Yes
Automatic migration possible:
Yes
Additional implications:
- Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.