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. https://github.com/kitodo/kitodo-production/commit/ca030766d9d0770a5eba8b0fada3163686c1f06c), 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:

• https://github.com/kitodo/kitodo-production/discussions/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.