Can anybody help in knowing that IFC entites are Case Senstive or Case insenstive.
like
Can we write IFCPERSON as IfcPerson (camel case)** and ifcperson (small)
in an .ifc file.
Some vendors says they are Case sensitive and some says case insensitive.
Can you helping knowing what is exact and correct method of writing enties.
Please answer with proof so that i can continue my research work.
I have answered this here already: Is the IFC entities are case senstive?
It should be UPPERCASE. The proof is in the STEP ISO 10303 specification which I link to in that post.
If a vendor has implemented it to be case insensitive, they are being lenient, but it is not technically correct according to the spec.
Welcome to the BSI forums 
FYI IfcPerson is CapsCase, not camelCase.
2 Likes
These all are iso Standards : http://www.steptools.com/stds/step/IS_final_p21e3.html
and not a detail about IFC entiies.
as
KEYWORD = USER_DEFINED_KEYWORD | STANDARD_KEYWORD .
USER_DEFINED_KEYWORD = “!” UPPER { UPPER | DIGIT } .
STANDARD_KEYWORD = UPPER { UPPER | DIGIT } .
SIGN = “+” | “-” .
INTEGER = [ SIGN ] DIGIT { DIGIT } .
these all are standard of iso 10303 and part 21 is used in IFC. from this we can say IFC is case senstive as ISO are case sensitive.
but
USER_DEFINED_KEYWORD = “!” UPPER { UPPER | DIGIT } .
STANDARD_KEYWORD = UPPER { UPPER | DIGIT } .
these doesn’t mean IFC entites are upper they are talking about keyword used in ISO like HEADER, FILE SCHEMA, RULE etc .
i need a proof which should explain IFCPERSON OR IFCUNITS are upper case or camal case IfcPerson like this.
i read all building smart website they only talk about GUID and UUID that they are case senstive not a single deatil about Entities of ifc
see link http://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/
they are using camel case everywhere to define entites
IFC uses the STEP 10303 ISO standard.
Things like HEADER; are not keywords. Keywords are defined by the WSN in the spec.
For example, please see Table 3 — WSN of the exchange structure as it explains how the syntax works. In particular, here is an example line which describes a typical line in an IFC file:
SIMPLE_ENTITY_INSTANCE = ENTITY_INSTANCE_NAME "=" SIMPLE_RECORD ";" .
ENTITY_INSTANCE_NAME = "#" ( DIGIT ) { DIGIT } .
SIMPLE_RECORD = KEYWORD "(" [ PARAMETER_LIST ] ")" .
KEYWORD = USER_DEFINED_KEYWORD | STANDARD_KEYWORD .
USER_DEFINED_KEYWORD = "!" UPPER { UPPER | DIGIT } .
STANDARD_KEYWORD = UPPER { UPPER | DIGIT } .
As you can see, in a line like #1 = IFCPERSON(...), IFCPERSON is a KEYWORD, so that’s why it needs to be uppercase.
1 Like
But if you refer building smart link then why they are not writing in CAPS , thet are using camel case everywhere see the link or website
IFC is a specification which can be written into different formats (.ifc, .ifcxml). If you check this page you will see how the .ifc exchange format is defined (which is one out of three current possible exchange formats listed on that page).
IFC data file using the STEP physical file structure according to ISO10303-21. The *.ifc file shall validate according to the IFC-EXPRESS specification.
This is the default IFC exchange format.
The HTML specification could theoretically use whatever naming convention it wanted as long as it was clearly communicated how to denote it in each exchange format.
The example you give is not official, and in fact it looks as though it is XML, not an .ifc format. XML follows different rules.
ok I may agree with you ,
But i have certain more issue on IFC case sensitive
Like on using IFCOPENSHELL with python i used to extract IFC entities, the extraction give all entities in Camal Case in .ifc file. Why so?
also Camel Case IFC are opened by many Big vendors like Bentley , Bim vision etc IFCPLUSPLUS also open camel Case. Why?
IfcOpenShell is a Python library that parses an .ifc file and returns it in Python objects for easy access. There is no ISO standard on how Python objects should be named, but there are programming conventions: for example, globals and constants in programming are likely to be all uppercase, classes in some languages are CapsCase, and Python actually is idiomatically more lowercase using underscore separators. This is evident by things like the is_a() function in IfcOpenShell, which uses a more Pythonic convention. In short, IfcOpenShell can use whatever they want. They probably uses CapsCase because they are in fact automatically extracting values based on an computer interpretable XSD or similar (I need to check).
Programs like Bentley, BIM vision and IfcPlusPlus are not strictly adhering to the ISO spec, and that’s why they can open the files. The good news is that keyword case sensitivity is unlikely to impact the quality of the data itself, I wouldn’t worry too much about it
I am working IFC .
It is open source and Everyone says it too, but i am working from 7 month on IFC and i found some new query in IFC weekly and that are HIDDEN puzzles.
Every one had made there own IFC formats by there own wish or we can say as per there needs.
It is becoming so much jumbled that no 2 software’s transfer just 50 to 60 percent data.
ALSO read this link from building smart :-
http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/introduction.htm
- the data item names for types, entities, rules and functions start with the prefix “Ifc” and continue with the English words in CamelCase naming convention (no underscore, first letter in word in upper case);
- the attribute names within an entity follow the CamelCase nameing convention with no prefix;
@Tandeep, the naming conventions used in the data specification are independent from naming conventions used in the .ifc file transfer format. The .ifc file has to follow the STEP ISO rules to be syntatically correct, because it is defined that that is the format for .ifc. It is normal to have a spec that has a different naming convention to a format. If you are referring to the spec itself and not a keyword within an .ifc file, please use Caps Case.
You have highlighted that the spec uses the word “camelCase”. This is a little misleading. I think instead they should say upper camel case, or Pascal case (I use CapsCase, but perhaps that is less official of a word).
1 Like
Can we write IFCPERSON as IfcPerson (camel case)** and ifcperson (small)
in an .ifc file
More precisely, IfcPerson is in PascalCase and ifcPerson is in camelCase.
Simply put,
The .ifc file is ALWAYS upper case. As @Moult says, this is due to ISO 10303-21. To date, IFC is a slight semantic derivation of STEP, but still follows the general implementation rules.
The documentation is CapsCase for human readability. It allows the eye and mind to quickly discern content differences.
Hope that helps.
2 Likes
In case of P21 format => IFCPERSON, Incase of IfcXML IfcPerson.
1 Like
Sir i am agree with all that IFC is written in upper case and it is case sensitive.
But now i had one more question.
why building smart is giving certificate to that companies and software which are violating the basic format of IFC files.
Thank all for helping.
Can you give two or three examples to support your observation.
1 Like
Sorry @Tandeep - nobody is violating!
In the EXPRESS - ISO 10303-11 - schema definition, identifiers (entity names, etc.) are case insensitiv. Here, by convension, buildingSMART is using CapCase, e.g. IfcCartesianPoint. In STEP protocols, like ISO 10303-42 for geometry, they use lower case, e.g. cartesian_point by convention.
In a serialisation, i.e. in clear text encoding of the exchange structure, see ISO 10303-21, all keywords are case sensitive and UPPER case. So IfcCartesianPoint -> IFCCARTESIANPOINT in an ifc file, or cartesian_point -> CARTESIAN_POINT in an spf file.
This is what ISO 10303 defines. If you want to write correct ifc files, this is what you have to obay.
I suspect @tandeep is referring back to his observation here. I do not use Bentley software so I cannot comment.
However, I have used IfcPlusPlus, and I can confirm that IfcPlusPlus’s IfcQuery does indeed parse (i.e. deserialise) IFC files without taking into account keyword case sensitivity. However, IfcPlusPlus’s IfcQuery is not on the list of BuildingSMART certified software, so BSI is not at fault here.
I have tested both Graphisoft ArchiCAD and Autodesk Revit, which are both BSI certified software. Both software do indeed parse IFC keywords correctly and take into account case sensitivity. If a keyword has the wrong case, it will simply not import that particular IFC object. I believe this is correct behaviour.