buildingSMART / buildingSMART/IFC4.x-development
Clarification required on the inheritance and override behaviour of classification references
- Dominant language
- Python
- Stars
- 234
- Forks
- 123
- Avg merge
- 15h 4m
- Merged PRs (30d)
- 5
Description
The object typing and object properties concepts in chapter 4 describe how for things like properties, materials, predefined type, etc are all inherited and overridden with particular rules.
What isn't mentioned is how does this work for classification references?
Intuitively, if a type has a classification reference of FOO, then a human would expect occurrences to also inherit that reference of FOO.
But how do overrides work? If a type has a classification of FOO, and an occurrence has BAR, does the occurrence end up being both FOO and BAR as a union, or replaced with only BAR? If only BAR, that is consistent with the behaviour of how overrides work elsewhere. But, if a union, it may be conducive to workflows where a type may have a more generic reference, and a occurrence may have a more specific reference (especially in lightweight referencing).
Also, should overrides be specific / isolated to the classification system? E.g. if a type has classification Uniclass.FOO, and a type has Omniclass.BAR, then what should happen?
My proposal is that occurrence references should fully replace type references if present, even if classification systems differ. This makes the behaviour consistent with the rest of inheritance and overrides elsewhere, and is also simpler to implement so less headache for vendors or "gotchas" for users.
Contributor guide
Assessment
This issue has not been assessed yet.