Review parser/storer design

[etj]

The parser/storer design was introduced by GNIP 86 with the purpose of creating an easily extendable platform that would deal with different input metadata documents.

The new metadata editing approach described in GNIP 97 focus on the management of each single field.

At the moment the handlers defined in GNIP 97 are only used when editing the metadata in the client editor, but are not integrated yet with the procedures that set the internal metadata, reading them from an uploaded metadata document.

At the moment, the concepts of storers and metadata handlers conflict, since both their implementation deal with the persistence of the metadata elements.

The scope of the different agents may be:

• parsers: just parse the metadata document, providing a dict that contains custom keys and content extracted by the input document. This is a syntax-only operation.
• storers: adapt the custom keys to the json schema properties, also adapting the content if needed. They will no longer store the values, so we may want to change their name.
• metadata handlers: persist the metadata fields. Probably no change needed here.

Foreseen needed changes:

• the parsing procedure should not need to split the output into vals, regions, keywords, etc, since this is a semantic evaluation that is not needed at parse level.
• in the same way, storers should just get a single object (dict) containing all the parsed elements. They should create fragments of the json schema instance to be fed to the metadata manager.

The set of fields may be extended/updated by using the very same exisiting design:

• provide a new parser that will be called as the other ones: this new parser will extract fields from the metadata document and store them in new keys
• provide new metadata handlers that will handle the new field
• provide new storers that maps the new parsed fields into the json schema properties declared by the new handlers.