Use common base16 encoded GlobalIds instead of bespoke base64

[tldddd]

Currently STEP serialized IFC requires storing GlobalIds in a custom base64 format, more information here: https://technical.buildingsmart.org/resources/ifcimplementationguidance/ifc-guid/

As described on the linked page, this is purely for historical storage reasons, the amount of space that it saves in the modern IT environment is insignificant.

IFC uses a bespoke base64 format which means common programming libraries can't read it without extra code. For example: "2Z_lemE5zDQQcXGoemo8lz".

IFC Implementors have to write their own algorithms to handle this.

The nature of base64 means that it is case sensitive. Some databases, Excel, Navisworks, and other tools are not case sensitive by default which causes problems when searching by GlobalId.

I suggest to use the common base16 encoding of GlobalIds for all serializations of IFC. For example: "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

It is not case sensitive, can be handled natively by many tools and databases, and is backward because you can still safely map between if so desired.

See: RFC4122 A Universally Unique IDentifier URN Namespace for more information.

[klacol]

I second this, @timchipman and me had a discussion about that some time ago: https://github.com/buildingSMART/IfcDoc/issues/30

The code to transform GUID's between the two notations should be open, to be able the migrate existing IFC GlobalId's to the new UUID-notation.

[tldddd]

There is code from buildingSMART that handles converting base64 to and from base16 but it is under AGPL so cannot be used within non-open source tools.

The IfcOpenShell code is under LGPL, and xBIM is under CDDL.

My understanding of these licenses is that this code can not be incorporated (copy / pasted) into closed-source software. If one of them could be under MIT or other permissive license then it would be trivial for implementors to convert from base64 IfcGloballyUniqueId to standard base16 GUIDs and back again.

[berlotti]

Great suggestion!

[janbrouwer]

+1

[pipauwel]

This is so obvious.... +1

[aothms]

Hi, we're working on providing some structure to the suggestions in this repo. Since this appears to be a clear case where everybody agrees. Let's take an example issue template for a test drive. What do you think of this template? Does it miss important characteristics? Note that not all points need to be satisfied, backwards compatibility and file size are not concerns.

---

what do we win

• interoperability with other systems
• less bespoke code
• less implementation error (some implementations emit invalid ids, eg. purely random characters)

what do we loose

• ?

schema impact

• revise IfcGloballyUniqueId type definition

instance model impact

• as described

backwards compatible

• no, violation of string fixed(22) type of IfcGloballyUniqueId, but impact minor.

automatic migration possible

• yes

file size implications

• Assuming we include hyphens en no braces this adds to 14 additional chars per guid. Example: nibs duplex model (1656153 bytes) has 3893 rooted entity instances, hence (3893 14) / 1656153 100 = 3.3% increase in file size.

are there other approaches to accomplish the same

• ?

[TLiebich]

Thanks to @aothms - I like this template - it should be the baseline to make informed decisions also on other issues.