search

buildingSMART / NextGen-IFC

61 stars 4 forks source link

IfcInteger vs INTEGER #80

Open pjanck opened 3 years ago

pjanck commented 3 years ago

Description of the proposal:

Moving from IFC4 to IFC4x1, EXPRESS::INTEGER (EXPRESS internal data type) was overall replaced with a defined type IfcInteger. However, this has apparently not been done for all instances - e.g. IfcDerivedUnitElement. I'm not sure if this is a design decision, or if this has been overlooked.

I propose to either use IfcInteger or INTEGER, but not both.

Describe how it contributes to the objectives (https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC): improves consistency.

Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one): change.

What do we win: consistency.

What do we lose: chaos.

Schema impact: yes.

Instance model impact: none (I believe).

Backwards compatible: ?

Automatic migration possible: yes.

Additional implications: Perhaps an overhaul should be done for IfcDouble and the rest as well.

jetgeo commented 3 years ago

Agree! See also the more general proposal on reusing already defined concepts, which includes reuse of primitive datatypes instead of defining them specifically for IFC : https://github.com/buildingSMART/NextGen-IFC/issues/53

devonsparks commented 2 months ago

+1. This looks like a straightforward fix. Minimizing the content surface between IFC "base types" (like IfcInteger) and EXPRESS primitives by using IFC's type definitions everywhere we can directly supports the bSI's technical objectives.