Use named IDs again when writing METS files

[matthias-ronge]

In the 2.x versions, named identifiers were written to the METS files, so FileSec entries got IDs FILE_0001, FILE_0002, FILE_0003, ..., DmdSec entries got IDs DMD_0001, DMD_0002, DMD_0003, ..., and that for all IDs assigned in METS files. This behavior has been replaced by the use of UUID strings (cf. ca03076), but in practice this is confusing when you look at a METS file in a text editor for debugging purposes. So I would like to reinstate the original behavior. The PR is also for a discussion about whether there are pros and cons to this, and which ones.

[andre-hohmann]

If this issue will be solved, the persistence of the ID should be regarded!

• In Kitodo.Production 2, the ID are numbered according to the sequence.
• In Kitodo.Production 3, the ID are numbered according to the object - at least for the object of the process (not for ID of superordinate processes, mets:fptr, ...). Therefore the ID of an object remains, even if a new element is created within an existing sequence in for example <mets:structMap TYPE="LOGICAL">.

Although i wanted the "name Identifiers" instead of the UUID, i am not sure, if it is a good idea to reinstate the original behavior.
Meanwhile, there are many objects with UUID and with regard to the persistence of ID, they should not be changed.
I tried to explain it in the following discussion:

• Anwendung und Persistenz der METS-Attribute ID (UUID) in Kitodo.Production 3 #5860

I understand your motivation, as I also analyse many METS files myself. Nevertheless, we should take a good look at how the desired goal can be achieved without causing further effort.