Front Page Forums imzML Software UUID encoding in the binary file

Viewing 1 post (of 1 total)
  • Author
  • #1270
    Angel Pizarro

    FYI for any developers, the encoded UUID of the binary format does not follow what a simple interpretation of the UUID spec would lead you to suppose. You cannot unmarshall all 16 bytes as one large hex string. You [b]must account for unmarshalling the separate UUID binary components using their data type + little endian.[/b]

    I found this out when implementing a ruby library for imzML. had a conversation with the imzML developers about the UUID encoded in the XML and binary files. I the UUID specification it clearly states that the encoding of the the 16 byte UUID is network, or big, endian. The current implementation of the RAW -> imzML converter, however, relies on Windows-API GUID implementation. From the email:

    the Windows-API: GUID-Structure which I use :

    [code]typedef struct _GUID
    unsigned long Data1;
    unsigned short Data2;
    unsigned short Data3;
    unsigned char Data4[8];
    } GUID;
    you will see, that the first 3 parts of the GUID (Globally Unique IDentifier is the MS-word for UUID) are integer datatypes.
    ( … )
    Have a look at my code
    if Assigned(FBinOutFileStream) then begin
    if (FShallGUIDBeInFile and FFirstTime) then begin
    FFirstTime := False;
    if not pNomzTrace then begin // mz Spur schreiben
    Result := FBinOutFileStream.Position;

    As you see (blue line) I just dump the GUID-structure as it is (byte by byte) to the filestream.
    This is also true for any other integer value which my binary component will write.
    Therefore our routines will write Little-Endian on our Little-Endian Processors.

    The UUID Ruby library assumes all 16 ytes are network encoded, so I was getting UUID mismatches.

    I am not sure what the end result will be, whether:

    a) the imzML specification will be changed to reflect that individual components of the UUID should be (un)marshalled separately (with integer values as little endian)

    or if

    b) the imzML group will change their code (and all exisitng files( to encode all 16 bytes of the UUID as big endian.

    Either is fine for me, I just need to know the definitive answer. In the meantime I’ll just assume that they will go for option (a) since that is the easiest to implement on their end.

Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.