36 describes a number of simplifications to the IFC "base" datatype system. Despite being marked as "decision made" with strong consensus, the base types called out for simplification remain in IFC4.3.
In particular, we call to remove IfcLogical and the underlying EXPRESS Logical type, replacing all occurrences with OPTIONAL IfcBoolean.
To maintain "technology independence", the model should be rooted in concepts that can be implemented in multiple schema language. Many schema languages support booleans and most support optional properties. Fewer support a true ternary data type. Replacing all instances of a ternary Logical type with an optional boolean simplifies integration.
Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one):
change
What do we win:
Schema simplification.
What do we lose
Explicit IfcLogical type, replaced by an OPTIONAL IfcBoolean pattern.
Schema impact:
Removable of all Logical types or their derivatives.
Instance model impact:
Replacement of Logical instance values with a Boolean or NULL ($ in STP).
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:
36 describes a number of simplifications to the IFC "base" datatype system. Despite being marked as "decision made" with strong consensus, the base types called out for simplification remain in IFC4.3.
In particular, we call to remove
IfcLogicaland the underlying EXPRESSLogicaltype, replacing all occurrences withOPTIONAL IfcBoolean.Describe how it contributes to the objectives (https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC):
To maintain "technology independence", the model should be rooted in concepts that can be implemented in multiple schema language. Many schema languages support booleans and most support optional properties. Fewer support a true ternary data type. Replacing all instances of a ternary Logical type with an optional boolean simplifies integration.
Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one): change
What do we win: Schema simplification.
What do we lose Explicit IfcLogical type, replaced by an OPTIONAL IfcBoolean pattern.
Schema impact: Removable of all Logical types or their derivatives.
Instance model impact: Replacement of Logical instance values with a Boolean or NULL ($ in STP).
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.