Changes between Version 1 and Version 2 of CMDI 1.2/Migration/Instance migration
- Timestamp:
- 10/31/13 15:30:08 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CMDI 1.2/Migration/Instance migration
v1 v2 7 7 == The issue == 8 8 9 Unlike [[CMDI 1.2/Migration/Component migration|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 is known for a conversion in the opposite direction. As is the case with upgrading components, this conversion should be mostly straightforward.9 Unlike [[CMDI 1.2/Migration/Component migration|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. 10 10 11 11 Special care has to be taken with CMDI 1.1 instances based on profiles that are in fact dumbed down versions of 1.2 profiles, see [[CMDI 1.2/Migration/Component migration#a1.2-1.1-1.2roundtrip|1.2 -> 1.1 -> 1.2 roundtrip]]. … … 13 13 == Proposed solution == 14 14 15 === Pros === 15 Develop an XSLT that 16 * changes the CMDI version number to 1.2 17 * changes the schema location of the instance to the 1.2 counterpart of the original profile (see [[CMDI 1.2/Migration/Component migration|component migration page]]) 18 * moves reserved attributes into the CMDI namespace (see [[CMDI 1.2/Attributes/Namespace|attribute namespace page]]) 19 * adds an MdProfile header if it was not present before (see [[CMDI 1.2/Header/MdProfile|MdProfile header page]]) 20 * applies any other required changes... (full list needs to be assembled) 16 21 17 Pros of this solution 18 19 === Cons === 20 21 Cons of this solution 22 The XSLT will be made publicly available so that any centre can apply it to their metadata instances as soon as they have made al required changes. 22 23 23 24 === Centre impact === 24 25 25 * Affected tools 26 * Impact on instances 26 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. 27 27 28 28 === Implementation examples === 29 29 30 * Implementation on model level 31 * Implementation on instance level 30 TODO: (Link to) transformation examples? 32 31 33 32 == Tickets == 34 {{{#!comment 35 Below replace the word 'keyword' in both the the text and the ticket query 36 }}} 33 37 34 Tickets in the CMDI 1.2 milestone with the keyword ''instancemigration'': 38 35 [[TicketQuery(keywords=~instancemigration,milestone=CMDI 1.2,format=table,col=summary|owner|component|priority|status)]]
