IfcInteger vs INTEGER

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.