This page is a subpage of CMDI 1.2
Migration issues for CMDI 1.2: Executive summary
This page provides an executive summary of the issue and proposed solution fully described in CMDI 1.2/Migration.
Issue description
Centres should migrate their metadata, tools and infrastructure to CMDI 1.2 if they want to keep up with current developments. Aspects of migration can be categorised as component, instance or tool related. Existing components and profiles should stay available as they are while newly created components and profiles should stay accessible to the existing infrastructure components. Instances need only be upgraded from 1.1 to 1.2 on a per-repository basis. Migration has varying impact on infrastructure components and tools, which needs to be assessed.
Description of proposed solution
Component migration
XSLT's will be created that operate on the component specifications for conversion between 1.1 and 1.2 and vice versa. An upgrade of all existing components will need to be carried out once, the result of which will be consolidated as the new state of the Component Registry. After this, the Component Registry can perform reverse conversion on request. These should result in functionally equivalents to the original specifications. An assessment has shown that cycles starting with original 1.1 components can be carried out without losing information. Components created newly in 1.2 cannot always be converted to 1.1 losslessly but poses no problem as there are no pre-existing instances.
A roundtrip starting with 1.2 is also possible and requires some attention as this is not guaranteed to be lossless and therefore instances conforming to an original 1.2 profile schema may not be valid with respect to the schema based on the profile converted back and forth. This will have to be taken into account when extending the Component Registry with conversion functionality.
Component migration will be carried out centrally and has no direct impact on centres apart from 1.2 versions of existing profiles becoming available, allowing for instance migration.
Instance migration
The CMDI taskforce will facilitate instance upgrading only, i.e. CMDI 1.1 compatible instances will need to be upgradeable to 1.2 but no valid use case for a conversion in the opposite direction has been raised.
An XSLT for general usage will be created that carries out the following changes to an existing 1.1 record:
- changes the CMDI version number to 1.2
- changes the schema location of the instance to the 1.2 counterpart of the original profile
- (updates the namespace [depending on the outcome of the namespace-per-profile discussion])
- moves reserved attributes into the CMDI namespace
- adds an MdProfile header if it was not present before
It should throw an error if:
- there are multiple values in a ref attributes
- no MdProfile or schema location was provided
Tool migration
The upgrade to 1.2 has the biggest impact on the ComponentRegistry. Next in line are CMDI editors, e.g., Arbil and Proforma, which need to become version aware and might need to support both 1.1 and 1.2 for a while. Other exploitation tools can cope, in general, by getting the code base to handle 1.2, and upgrade any 1.1 instances it needs to process using the migration XSLT.
