add script for addData

[Kathrin-Huber]

first part of #3368

only adding a new metadata is supported. Either by a given value or by a given metadata .

Not supported yet:

• deleting metadata
• overwriting metadata
• MetadataGroups overall

[matthias-ronge]

Before I start my review, first of all: I am pleased that you are making the copyData work again. But, I remember, we wanted to fundamentally reimplement it. Internally, the accesses are still passed on via the redirection interfaces for former UGH classes. In addition, new functionalities should be implemented, for example one should be able to access the parent documents. There was also an intranet page with a draft, but I'd have to look for it first.

Now to the specific pull request: Which of the following functionalities should be included in this PR?

/chapter[*]@destinationMetadataName = /@sourceMetadataName

1. add source to all destination divisions if source exists and destination metadata does not exist on destination division
2. overwrite destination metadata on destination division if source exists and destination metadata does exist on destination division
3. do nothing if destination metadata is unspecified="forbidden" on destination division
4. do nothing if destination division does not exist

/@kitodoProjectId = $process.project.id

5. like above, with internal object values

/@constantMetadata = "lorem ipsum"

6. like above, with strings

/chapter[*]@lastImage = #1/image[>]@index;

7. like above, but with metadata from the respective structure (in first chapter, use value from last image of first chapter, in second chapter use value from last image in second chapter…)

[Kathrin-Huber]

It's the smalles amount of funktionality.
It is adding a metadata at the given goal like @TitleDocMain
Its either filled with a given value (with "value") or it's taking the value of a given metadata (e.g @TitleDocMainShort)
It is always added to the root division, not concerning the ruleset.
Both things will be implemented later.
Also the replacement of object values (e.g. $process.project.id) is implemented later.

Can you point out, where old ugh classes are used?

[matthias-ronge]

Can you point out, where old ugh classes are used?

• class CopierData uses LegacyDocStructHelperInterface, LegacyMetsModsDigitalDocumentHelper and LegacyPrefsHelper (imported)
• class DataCopyrule uses LegacyMetsModsDigitalDocumentHelper (line 51, getDigitalDocument())
• classes DestinationReferenceSelector, MetadataPathSelector and MetadataSelector use LegacyDocStructHelperInterface (also imported)

[Kathrin-Huber]

None of those classes are used anymore in the KitodoScripts.
Stuff for export is adjusted later.

[matthias-ronge]

What you are doing here is incompatible to the copyData syntax we used so far. Is this intentional? Your test may work, but only because it uses a "wrong" String script (assuming that the old syntax should be retained).

String metadataKey = "LegalNoteAndTermsOfUse";
String script = "action:addData " + metadataKey + "=PDM1.0";

So your copyData command is:

LegalNoteAndTermsOfUse=PDM1.0

But it should look like this:

/@LegalNoteAndTermsOfUse = "PDM1.0"

/ is the logical root element of the structure tree, @ means: descend into attached metadata structure (not in logical structure), here points to a metadata key LegalNoteAndTermsOfUse. White space. It is a question if white space is required for parsing the copyData commands. The old parser needed it. It should at least be optional. = overwrite or create operator. White space. String in quotes, to indicate it is a string.

(Left side argument must always start with a / character, right side arguments must always start with one of the following characters: / (metadata), " (constant string), $ (toString() of internal variable), or # (select division relative to left side).)

I see two different approaches here.

1. If you want to quickly find a solution to add metadata to the root element of the logical structure tree, implement exactly that in the KitodoScriptService. In that case you don't need any special syntax, just:

• action:addMetadata key:LegalNoteAndTermsOfUse value:PDM1.0
• action:copyMetadata key:LegalNoteAndTermsOfUse value:TSL_ATS

2. If the aim is to bring the copydata functionality back, we should then write tests first (or even: we should first work out the syntax that will be needed in the future. There were approaches to this in the intranet. And then write tests). And then implement the functionality so that the tests no longer fail. There is a large amount of functionality in this. Getting this right is not trivial.

This review is not an approval or a rejection. If you intend to change the existing copyData syntax, your PR should do what it does. In that case, it would be good to document the new syntax.

[matthias-ronge]

please use: Helper.setErrorMessage(e.getMessage(), logger, e)

[Kathrin-Huber]

I'm going to remove this class, and as PRs are stacking up please be generous to spare me conflicts. :-)

[Kathrin-Huber]

This is a reimplementation of the copyData script. The resulting syntax may be slightly different, but the implementation is not done yet.
Currently, the metadata is always added at root level, so no selector at the goal metadata is requeired, just the key of the metadata.
If the selector functionality is implemented, a syntax for level selection will be integrated. I'm not sure yet, if this will map the old syntax, by I'm going to try to restore it.

[Kathrin-Huber]

is replaced by #4112