Roadmap

Organize Constants

Reused constants should be collected into bespoke classes as appropriate, instead of being scattered across the component.

Get URI from Data Factory

Get URI from the data factory, instead of instantiating it directly.

Clean up Remains of Migrations for Ilias 10

With ILIAS 10, the migrations ilMDLOMConformanceMigration and ilMDCopyrightMigration can be deleted. To clean up the migrations, the following table columns should be dropped:

• il_meta_general: coverage, coverage_language
• il_meta_meta_data: meta_data_scheme
• il_meta_requirement: operating_system_name, os_min_version, os_max_version, browser_name, browser_minimum_version, browser_maximum_version
• il_meta_educational: learning_resource_type, intended_end_user_role, context
• il_md_cpr_selections: copyright, language, costs, cpr_restrictions, migrated

Location Type

Check whether the field 'location_type' in the table 'il_meta_location' can be removed. Location type can be set in the old MD editor, but is not part of the LOM standard. It would be nice to get rid of it, should it not be used anywhere else in ILIAS.

Replace Generic Generators With Custom Iterators

A lot of generic generators are used throughout the component, along with quite a few usages of iterator_to_array. These should be gradually replaced by bespoke iterator classes.

Make Greater Use of Null Objects

null as a return type should be replaced by proper null objects. A good starting point might be Tags from Dictionaries.

Stricter formatting of 'format' and 'entity'

The fields technical>format and the various entities should conform to different standards (e.g. entities should be vcards). This could be supported better in ILIAS, currently any string is valid.

Allow INDEX path filters in search

It should be investigated, how path filters of type INDEX can be taken into account in the search, to allow for search queries like 'Find objects where the first author is Dr. No'.

These filters make translating the search queries to SQL much more complex, so the cost might outweigh the use.

Allow manipulation of LOM sets during derivation

The Derivator in the API could be expanded to contain methods like prepareOmit and prepareAddOrChange to allow changes to the derived LOM set before it is persisted. The repository would need to take into account more types of markers/scaffolds in transferMD.

Abandon the old backend

All ILIAS components using MD should at some point only use the new classes as the new MD editor does.

Only a few usages of the deprecated classes remain, most of these related to export/import. Those and all deprecated classes will be removed with ILIAS 10.

Customizable LOM Digest

Customizing of LOM Digest could be made possible for plugins, in order to tailor the screen better to every installations configuration.

Clean up Elements Folder

Currently, the Elements folder does not have its own service, so creation of the factories contained therein is not centralized.

For the factories for elements and structure elements, centralization does not make much sense: those elements only make sense when created in bulk and corss-referenced (sub- and super-elements), but the factories only offer creation of single objects. The actual creation of elements in context is done by higher order infrastructure such as the repository. Those factories should thus only be created for that specific part of the infrastructure and not reused.

Factories for scaffolds, ressource IDs and data on the other hand can be reused just fine, and should be offered through a service. Markers are a special case, I'm not sure whether they are needed outside of the manipulator.

Internationalization of LangStrings

Elements consisting of a string and a language could be allowed to contain multiple such tuples, such that e.g. translations of the title can be stored in LOM.

This would need expansive changes to the database structure, and a new input element for multilangual text input.

Clean up Dependency Management

Most of the dependency management happens in the Services folders, but in some places Initiators are used in tandem with the Services. Either Initiators should be used consistently for every entry point into MetaData (and Services reserved for things used across 'sub-components'), or everthing should be done in Services.

Further, Settings should also be refactored to use Services properly.

Improve Unit Test Coverage

The following classes are not yet covered by unit tests:

• everything in Editor
• everything in Settings except Vocabularies\Import
• GlobalScreen/ilMDKeywordExposer
• Manipulator/ScaffoldProvider
• everything in Paths
• everything in Repository, Repository/Utilities/Queries/DatabaseSearcher, and Repository/Utilities/Queries/Paths
• Services\InternalServices (along with all Services used by it), also all methods in Services\Services that don't do anything except lazily instantiate an object
• Vocabularies\Standard\Assignment, Vocabularies\Controlled, Vocabularies\Manager, Vocabularies\ElementHelper, and everything in Vocabularies\Slots
• XML/Copyright, XML/Links, XML/Dictionary, XML/Writer/SimpleDC, and XML/Reader/Standard/Legacy
• OERExposer/OAIPMH/HTTP, OERExposer/OAIPMH/Initiator
• OERHarvester/RepositoryObjects, OERHarvester/Settings, OERHarvester/Results, OERHarvester/Initiator