Moult
commented
4 years ago I don't quite understand this issue - this is phrased as a question, not an issue.
Here's a stab at an issue:
Improve documentation to clarify that IFC classes are non-case-sensitive within the schema (i.e. agnostic of format), but the following conventions are established:
- A strict convention of UPPERCASE is established for the IFC-SPF format
- A strict convention of CapsCase is established for the IFCXML format
- A suggested convention of CapsCase is established for the online documentation
- A recommended convention of CapsCase is established for agnostic references in text documents
What do we win: Less confusion? What do we lose: Nothing Schema impact: N/A Instance model impact: N/A Backwards compatible: N/A Automatic migration possible: N/A
Refer to discussion: https://forums.buildingsmart.org/t/ifc-entities-are-case-sensitive-or-not/1143
Description of the proposal: Do we need to enforce case in the schema/documentation?
Describe how it contributes to the objectives set in https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC:
What do we win:
What do we loose
Schema impact:
Instance model impact:
Backwards compatible:
Automatic migration possible:
Additional implications:
- Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.