search

buildingSMART / NextGen-IFC

61 stars 4 forks source link

Replace enumerating where rules with enumerations #82

Open hlg opened 3 years ago

hlg commented 3 years ago

There are few defined types that seem to effectively be enumerations, but modelled as strings with a value restriction by where rule, namely (in IFC4) IfcFontStyle, IfcFontVariant, IfcFontWeight, IfcTextAlignment, IfcTextDecoration, IfcTextTransformation, IfcBoxAlignment (the latter differing from the others by using IfcLabel rather than STRING as underlying type). Here is an example:

TYPE IfcFontStyle = STRING;
   WHERE
      WR1 : SELF IN ['normal','italic','oblique'];
END_TYPE;

It might be reconsidered to change these to defined types with ENUMERATION as underlying type. I assume that there has been a reason for modelling it this way. Maybe the reason was IfcFontWeight which contains enumeration IDs starting with a digit (e.g. 'normal','small-caps','100','200','300' ...) - something that is not allowed for enumeration IDs in EXPRESS. Similar reasoning for the dashes in IfcBoxAlignment.

Changing these types to be based on enumerations would reduce the modelling constructions used for the same meta semantics and thus simplify the schema. Conversion between modelling languages would be simplified. The way it is now, when converting from UML to EXPRESS, for example, it can not be automatically inferred whether an enumeration or this construction should be used.

If numeric font weight values can not be prefixed with a letter, this would leave us with considerable inconsistency in how the various font defining parameters are modelled, but at least it could be based on a defined criterion (contained values starting with a digit). If on the other hand font weight values are prefixed with a letter to remove all such constructions, then we loose conformance with Cascading Style Sheets. I don't see a direct reason against replacing the dash in IfcBoxAlignment with an underscore.

Instance model would change and not be compatible with earlier schema versions, but automatic migration would be possible.

devonsparks commented 2 months ago

I've wondered about this too. Consulting Schenck, substituting the string-based where rules with enumerations appears to be semantically consistent, because we're still defining a dedicated TYPE. There are a few edge cases to work through (like FontWeight, as you highlight) but they're minor relative to the value-add of consistency, and automatic migration is possible.