# About IFC Header section **URL:** \ **Category:** Developers\ **Created:** [March 20, 2020, 8:33am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522 "2020-03-20T08:33:24Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![claimred](https://avatars.discourse-cdn.com/v4/letter/c/e47c2d/32.png) [@claimred](https://forums.buildingsmart.org/u/claimred)\ **Post date:** [March 20, 2020, 8:33am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/1 "2020-03-20T08:33:24Z")
It’s recommended to use full local path in native Windows format using ‘\’ slashes. But it sort of conflicts with the idea of step encoded substrings in the path. Possible to get confusing paths, like FILE\_NAME(‘F:\X2\041D043E0432044B0439\X0\ \X2\043F0440043E0435043A0442\X0.ifc’) ![image](https://us1.discourse-cdn.com/flex016/uploads/buildingsmart1/original/2X/1/1fb0ebc0a89fb21d77fb5fb49ffedf90e5d90650.jpeg) ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [March 20, 2020, 9:17am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/2 "2020-03-20T09:17:05Z")
Where are you reading that it is recommended to use full local path using native Windows format? As far as I am aware, the [STEP ISO standard](http://www.steptools.com/stds/step/IS_final_p21e3.html#clause-8-2-3) only defines it as `STRING (256) ;` and states the following: > name: the string of graphic characters used to name this exchange structure. Two exchange structures with the same name shall use compatible representations for anchors with the same anchor name. > > The use of an object identifier within the name is recommended but not required as it provides unambiguous identification of the anchor structure. > > If an object identifier is provided, it shall have the form specified in ISO/IEC 8824-1. The use of object identifiers within this International Standard is described in clause 3 of ISO 10303-1. > > EXAMPLE > name Example usage > > brep\_shape Exchange structure has the anchors of a Brep shape model > PMI{ 1 2 10303 501 0 1 1 1 } Exchange structure has the anchors of a PMI model version defined by the \> OID ---
**Author:** ![claimred](https://avatars.discourse-cdn.com/v4/letter/c/e47c2d/32.png) [@claimred](https://forums.buildingsmart.org/u/claimred)\ **Post date:** [March 20, 2020, 9:31am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/3 "2020-03-20T09:31:37Z")
Well, I kinda interpreted path example provided here [https://standards.buildingsmart.org/documents/Implementation/ImplementationGuide\_IFCHeaderData\_Version\_1.0.2.pdf](https://standards.buildingsmart.org/documents/Implementation/ImplementationGuide_IFCHeaderData_Version_1.0.2.pdf) as a requirement. Do you think it’s ok to provide local path as a ‘C:/folder/project.ifc’? How do you deal with local paths in Blender? ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [March 20, 2020, 9:51am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/4 "2020-03-20T09:51:46Z")
I see. In the BlenderBIM Add-on I have implemented it as the filename, devoid of the absolute path. e.g. `FILE_NAME('test.ifc',...` I personally see very little utility in the absolute path, and especially less utility in Windows-style path separators which tend to make things a bit more annoying when later integrating it on a network. Therefore I don’t run into the Windows vs Unix style path separators. I see that in ArchiCAD they have implemented a full path with Windows-style path separators, but unlike that PDF which gives `FILE_NAME('C:\IAI_Test_Building.ifc'...` as an example, ArchiCAD escapes it, e.g. `FILE_NAME('D:\\00-Oficina\\10BIM\\ANALISIS IFC\\ARCHICAD 23_COLUMN.ifc'`. This seems like a sensible solution, and points out a flaw in that PDF. Revit ignores it altogether and goes pure STEP and just gives it the same value as the IfcProject Name attribute. E.g. `FILE_NAME('Project Number',...`. Ping @TLiebich who can perhaps verify what the original intent was? There seems to be a clear discrepancy in implementation. ---
**Author:** ![TLiebich](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/tliebich/32/71_2.png) [@TLiebich](https://forums.buildingsmart.org/u/TLiebich)\ **Post date:** [March 20, 2020, 10:48am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/5 "2020-03-20T10:48:57Z")
Hi @Moult, so far, there are no additional instruction (over and above what ISO10303-21 defines). A few (actually quite a few) years ago we published an IFC Header Implementation Guide (I attach it) were instructions had been formulated in how to generate the IFC file header. But this did not handle the specifics of the file name. Question to all: would such an agreement been helpful? Should an update of the header implementation guide be published? Who would contribute? [ImplementationGuide\_IFCHeaderData\_Version\_1.0.2.pdf](https://forums.buildingsmart.org/uploads/short-url/ad1SIwDZ3r5TJnzyEYFS3uZf2IT.pdf) (106.4 KB) ---
**Author:** ![claimred](https://avatars.discourse-cdn.com/v4/letter/c/e47c2d/32.png) [@claimred](https://forums.buildingsmart.org/u/claimred)\ **Post date:** [March 20, 2020, 11:26am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/6 "2020-03-20T11:26:07Z")
Thanks for chiming in! What was the original intent behind using full local path for header section? ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [March 20, 2020, 10:08pm UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/7 "2020-03-20T22:08:58Z")
@TLiebich - that implementation guide is the same as the one that @claimred found online 🙂 I think an agreement would be helpful, and I would love to contribute. May I also recommend, along with [issue 42](https://github.com/buildingSMART/NextGen-IFC/issues/42), that similar to how implementer agreements can be merged into docs, that all guidances on [this page](https://technical.buildingsmart.org/resources/ifcimplementationguidance/) also be merged into official documentation and then linked on the [IFC formats](https://technical.buildingsmart.org/standards/ifc/ifc-formats/) page? For now, perhaps just republish the guide and link it from the IFC formats page, but in the future it would be very good to convert it from PDF into HTML. ---
**Author:** ![TLiebich](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/tliebich/32/71_2.png) [@TLiebich](https://forums.buildingsmart.org/u/TLiebich)\ **Post date:** [March 22, 2020, 8:59pm UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/8 "2020-03-22T20:59:14Z")
@claimred - there was not a real intention - it was only an example (the “C:\IAI\_Test\_Building.ifc”). Currently there is no guideline on how to fill in the `FILE_NAME.name` attribute. ---
**Author:** ![claimred](https://avatars.discourse-cdn.com/v4/letter/c/e47c2d/32.png) [@claimred](https://forums.buildingsmart.org/u/claimred)\ **Post date:** [March 24, 2020, 4:45pm UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/9 "2020-03-24T16:45:10Z")
> [@TLiebich](#): > > Currently there is no guideline on how to fill in the `FILE_NAME.name` attribute. Got it, thanks. Another thing that should be clarified imho is whether filename is actual ifc _file name_ or name of the internal software project. Revit & Archicad behave differently. ---
**Author:** ![claimred](https://avatars.discourse-cdn.com/v4/letter/c/e47c2d/32.png) [@claimred](https://forums.buildingsmart.org/u/claimred)\ **Post date:** [June 25, 2020, 11:22am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/10 "2020-06-25T11:22:13Z")
It looks like `schema_identifiers` filed should also be clarified in the header implementation guide. According to several questions here: > [@Versioning in the IFC-file](https://forums.buildingsmart.org/t/versioning-in-the-ifc-file/2796/2): > > I have seen a list of schema identifiers in IfcOpenShell: [https://github.com/IfcOpenShell/IfcOpenShell/blob/f01ae4a45b3fc294ab5bcd4de494cc446ac587dc/cmake/CMakeLists.txt#L462](https://github.com/IfcOpenShell/IfcOpenShell/blob/f01ae4a45b3fc294ab5bcd4de494cc446ac587dc/cmake/CMakeLists.txt#L462) set(SCHEMA\_VERSIONS "2x3" "4" "4x1" "4x2" "4x3\_rc1") I don’t know if they are official buildingSMART ones, or specific to IfcOpenShell. If buildingSMART does indeed have a list of official identifiers, then indeed, perhaps the vendors are just neglecting them or are unaware slight_smile Would be interested to know the … > [@FILE\_SCHEMA vs. Schema Version](https://forums.buildingsmart.org/t/file-schema-vs-schema-version/2750): > > Hello all, we faced some difficulties to import IFC4 files. The FILE\_SCHEMA tag indicated IFC4 FILE\_SCHEMA((‘IFC4’), but finally it contains data based on Schema version 4.0.2, IFC4 Add2, with some new items. As we are using a generative importer to make sure the schema is correct, we like to know the real schema content of a file and not only the major version. Version 4 already has a lot of addendum and extensions. So I like to know how to judge the correct Schema Version of an IFC4 file. Ma… ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [May 28, 2021, 12:01am UTC](https://forums.buildingsmart.org/t/about-ifc-header-section/2522/11 "2021-05-28T00:01:15Z")
The appendix in the header implementation guide seems a bit outdated now (especially given the 20 or so relatively new MVDs that have popped up in the MVD database). Perhaps it is worthwhile to migrate this PDF guide to a webpage so that it can be version tracked and easily updated?