This page is a subpage of CMDI 1.2
Migration of CMDI instances from CMDI 1.1 to 1.2
The issue
Unlike component migration, instance migration involves upgrading only, i.e. CMDI 1.1 compatible instances will need to be upgradeable to 1.2 but there no valid use case for a conversion in the opposite direction has been proposed. As is the case with upgrading components, this conversion should be mostly straightforward.
Special care has to be taken with upgrading of CMDI 1.1 instances based on profiles that are in fact dumbed down versions of 1.2 profiles, see 1.2 -> 1.1 -> 1.2 roundtrip.
Proposed solution
Develop an XSLT that
- changes the CMDI version number to 1.2
- changes the schema location of the instance to the 1.2 counterpart of the original profile (see component migration page)
- moves reserved attributes into the CMDI namespace (see attribute namespace page)
- adds an MdProfile header if it was not present before (see MdProfile header page)
- (updates the namespace [depending on the outcome of the namespace-per-profile discussion])
And throws an error if:
- there are multiple values in a ref attributes
- no MdProfile? value or schema location was provided
The XSLT will be made publicly available so that any centre can apply it to their metadata instances as soon as they have made all other required changes to their infrastructure.
Overview of implications for instance migration of the various CMDI 1.2 specification topics
Centre impact
Centres can apply the XSLT to their instances as soon as their infrastructure is ready to deal with these. If their CMDI is generated, for example from a database, they might choose to adjust their generation facilities or simply add the transformation step to their processing chain.
Tickets
Tickets in the CMDI 1.2 milestone with the keyword instancemigration:
Discussion
Oddrun: Not sure I understand why downgrading instances is not relevant. If some Clarin node who chooses to stick with 1.1 wants to harvest metadata from a node serving 1.2, downgrading those data could be necessary. Unless one can be sure that absolutely all tools/software are able to handle both format from the moment go.
Axel Herold?: I'd guess that scenario would apply rarely. We could/should ask the centres whether they would stick to 1.1 while consuming with 1.2 instances provided by others. However, I would propose placing the development/maintenance burden on those center.
Twan: This document assesses the implications for instance migration of the the various topics. Some aspects of the downgrade can be tricky. I think we should not want to promise an out-of-the-box downgrade but leave it up to the centres as Axel proposes.
