buildingSMART
Specify a UUID version for GlobalIds
Description of the proposal:
Please see here for UUID versions: https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions
Also, this is related to #8
I am not currently aware of a UUID version being specified in the docs. This can lead to differing expectations.
I would personally prefer maximising randomness. If we are going to have BIM models of entire cities, we want to prevent collisions.
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:
Consistency.
If UUID4 is chosen, then randomness too, so we can have the world in a model :)
What do we lose
Inconsistency.
Some devs need to revisit their code.
Schema impact:
None really.
Instance model impact:
None really.
Backwards compatible:
Yep.
Automatic migration possible:
Yep.
Additional implications:
Note that not all points need to be satisfied! Backwards compatibility and file size are not concerns.
My proposal is for UUID4, yes. However, this is not my area of expertise, so I would seek more experienced advice before making a decision. I do believe that specifying a standard version is better than the current scenario where the developer may approach it however they wish.
Also not an expert, so a non-expert question: Isn't the current 'do whatever you want' giving defacto the same result as the UUID4 Random approach?
Unfortunately not, hence why some implementers are asking about the behaviour of the null UUID. I've seen implementers also choose to simply increment a number for "on-the-fly" exported IFC objects. Revit, for instance, has a interesting scenario where they use a few magic numbers, as well as an arbitrary XOR statement with a non-unique ElementId, which has also resulted in bugs where the IFC Guid in Revit and the IFC Guid that is in the file don't match, so we actually can't trust these and tend to re-generate them whenever we receive IFCs from Revit.