allow regexp matching in workspace operations

IMO at least the following operations (both in the CLI and API) on METS deserve allowing regular expression matching:

• remove_file: instead of a fixed ID to look for
• remove_file_group: instead of a fixed ID to look for
• find_files: both MIME type (e.g. just image/) and ID
• add_file_group: for both file names and file IDs (possibly with back-references), cf. discussion here

To minimise possible ambiguity between a verbatim string and regex interpretation, while still keeping the existing argument/option names (and not introducing a new flavour each time), I recommend either using POSIX Basic Regular Expression syntax (which is perhaps hard to get by in Python) or allowing some kind of extra notation in the input, e.g. a re: prefix.

[bertsky]

Sorry, just saw your response, already had #507 queued as fix.

feature would be self-documented via help strings in ocrd workspace.

Will do.

With the multi-valued semantics (and return-type) of ocrd_mets.remove_file, now we cannot simply delegate from workspace.remove_file

I’ll mirror the behavior in METS with remove_file/remove_one_file.

I did without mirroring…

[kba]

I agree these make sense and I can implement them. This is related to https://github.com/OCR-D/core/issues/446#issuecomment-590328336 (inefficient find_files) and #448, so I’m implementing it as part of #448. Have a look at https://github.com/kba/ocrd-core/commit/8b6d277640335bf8afa1d815f0cf26f5b9290060, this implements the regex search for find_files with a re: prefix, i.e. you can do mets.find_files(mimetype="re:image/jpe?g") or mets.find_files(ID="re:.*0001.*").

Since this is coupled to the “single-pass find_files changeset”, I still need to do performance testing but do let me know if this is going in the wrong direction.

Not sure about the re: prefix because of possible conflicts. How about ~ or @ which are presumably more rare in digitization data than re:?