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’)
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 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 usagebrep_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
Well, I kinda interpreted path example provided here 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?
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.
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 (106.4 KB)
Thanks for chiming in! What was the original intent behind using full local path for header section?
@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, that similar to how implementer agreements can be merged into docs, that all guidances on this page also be merged into official documentation and then linked on the 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.
@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.
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.
It looks like schema_identifiers filed should also be clarified in the header implementation guide.
According to several questions here:
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?
