buildingSMART / buildingSMART/NextGen-IFC

Replace enumerating where rules with enumerations

Open
#82 1 comment 3 reactions 0 assignees View on GitHub
enhancement valid proposal
Dominant language
TeX
Stars
64
Forks
4
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.