IFC4X3_ADD2 - Implementers Stance on IFC-GUID

[gmn3DS]

Hello,

The encoding process behind the creation of an IFC-GUID has been made more explicit in IFC4X3_ADD2 compared to prior ISO versions.

Though it might have been followed implicitly by some, it is now part of the official documentation.

In previous ISO versions, IFC2X3 and IFC4 I assume that the following rules were the basis for checking an IFC-GUID correctness:

• It is a STRING
• As a string, its length equals 22 characters
• All of its characters must be in the official base64 encoding character set
• It is unique within the file

Base 64 Encoding Character Set
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_$"

Starting IFC4X3_ADD2, the following rule could be added:

• The first character must be either a 0, 1, 2, or 3.

I wrote "could" because it brings me to the title of this topic.
I don't know if this rule should be strictly enforced or not, so let's open the discussion:

What is the implementers stance on this?

@evandroAlfieri I wrote a simple IFC4X3_ADD2 test file in which I listed all the GUID invalidity cases I could think of.

IFC4X3_ADD2_GuidTests.ifc.txt
I ran it inside the validation service and only one case appeared as invalid.

For people interested, I think it would also be a good foundation for a workshop dedicated to understand how to write custom ( / or soon to be implementers-approved) rules for the validation service.

Best Regards,
Guillaume

[evandroAlfieri]

copied over from @AngelVelezSosa on Slack

I don't know if this is the right place to comment, but I think "could" should be "must". The IfcGUID has a 1-1 conversion to a regular Guid, which would not be true if the first character were greater than 3.

[AngelVelezSosa]

Thanks @evandroAlfieri! What he said I said :)

[aothms]

The IfcGUID has a 1-1 conversion to a regular Guid

For specific versions and variants additional bit patterns may be invalid. Are these also things we want to check for? This may be something that needs to be augmented over time, cfr the v7 guid which was standardized not so long ago.

[AngelVelezSosa]

I don't know that IFC needs to be concerned about the specifics, just that it is potentially a valid GUID. It isn't if the first number is 4.

[SamiLyden]

Afaik this has always been the case. For one, it is not a 22 character string, it is a 128 bit number, And the string is an encoded version of this number. Unfortunately you can write invalid string manually and its not very clearly stated in previous documentations why this is the case.
From IFC4X
"An IfcGloballyUniqueId holds an encoded string identifier that is used to uniquely identify an IFC object. An IfcGloballyUniqueId is a Globally Unique Identifier (GUID) which is an auto-generated 128-bit number."

all the way to IFC2x (oldest one I can find)
"An identifier is a unique 128-bit number. ... The resulting string is a fixed 22 character length string to be exchanged within the IFC exchange file structure."

(also currently several sample files in 4x3 documentation now have invalid guids)