At the moment the non-permanent GUIDs are “faked” to look like the permanent GUIDs, but there should not be any real need to do. This is only causing problems to regression testing , to diffs, etc.
Therefore I’m proposing to have an null-GUID for non-permanent GUIDs i.e. ‘0000000000000000000000’
The only thing what we need to agree is that this particular GUID value has a special nature and does not need to be unigue in the IFC model. Many entities could share the same GUID.
This would also improve the certification process and testing , because now the non-permanent GUIDS are more visible.
This agreement has no effect to permanent GUIDs of physical entities.
Of course it would be the best not to need non-permanent GUIDs, but unfortunately that is not the case at the moment. For example property sets and quantity sets have GUIDs that needs to be created on-the-fly, because there is nothing corresponding in the native data model.
Good topic to raise, that is an alternative proposal to some suggestions that I (and others) might have about removing GlobalIds from relationships (or removing many relationships altogether). The requirement for a GlobalId to be optional on many derived classes would be a superior suggestion than using an empty/null guid in my opinion.
+1 on @jonm’s suggestion, assuming there isn’t a usefulness of having UUIDs for things like PSets?
For instance, let’s say in an ideal future we can reference one IFC file from another. The architect models a room. He references a IFC files from a sustainability consultant. The sustainability consultant is only responsible for adding relationships and psets, and so therefore ideally his IFC file only contains those relationship and pset definitions. Or maybe the QS has an IFC file that only contains QTO elements. Is there a disadvantage to removing the UUID here? What is the UUID is the only way the QS has to link it to costing items? What if the UUID is way a sustainability consultant references data in his models? What makes an element “non-permanent”?
It is not like there are no non-rooted entities in the schema. I thought the whole idea of deriving from IfcRoot was to have owner history and identification. Removing this from IfcRoot derived entities would imply these entities should not be rooted in the first place.
Now, of course we can have a discussion if this makes sense for certain entities such as the suggested relationships and psets. There are probably pros and cons. As the description of both relationship and property set suggest, these are supposed to be objects. So, I would agree with @Moult and wouldn’t be too hasty with just removing them.