This page is a subpage of CMDI 1.2

Migration of component from CMDI 1.1 to 1.2

The issue

To reiterate, CMDI 1.2 will be the new standard but much of the existing infrastructure will, at least initially, keep depending on CMDI 1.1. Therefore a migration strategy is required that takes this into account, specifically by keeping existing components and profiles available as they are and making newly created components and profiles accessible to this part of the infrastructure as much as possible.

Proposed solution

The obvious solution is to create conversion XSLT's that operate on the component specifications (for both components and profiles) for conversion in both directions (1.1 <-> 1.2). 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 one-time mass migration, 'dumbing down' of component specifications (both new and old) to 1.1-compatible versions can be carried out by the Component Registry on the fly. For existing (native 1.1) components, this dumbing down should of course be lossless w.r.t. to the original version. Finally, special attention is required for the 1.2 roundtrip as will be described below.

Conversions to implement

1.1 -> 1.2 conversion

The conversion of components from 1.1 to 1.2 should be relatively straightforward, since 1.2 is mostly an extension with a number of options for stronger restrictions in the model but these don't have to be applied.

1.2 -> 1.1 conversion

The conversion of components from 1.2 to 1.1 should be considered a 'dumbing down' operation as most of the new features in CMDI 1.2 cannot be represented in a 1.1 Component Specification. Therefore, the conversion can be 'lossy' (depending on the CMDI features used in the 1.2 version), although that should not be problematic as instances will be based on either the 1.2 version or the 1.1 version.

Aspects of the following features will not be retainable during conversion from 1.2 to 1.1:

• Usage of attributes that are reserved in 1.1 (see Generic attributes in CMDI namespace/#236)
  • These can be retained if a special prefix in the local name is applied, e.g @ref -> @c_ref
• Linked open vocabularies (see Vocabularies/#369)
  • The link will disappear
• Closed open vocabularies (see Vocabularies/#369)
  • The vocabulary will be kept but references to the vocabulary will be lost
• Mandatory attributes (#274)
  • They will become optional
• Cues for tools
  • Cues that did not exist in 1.1 will be skipped

1.1 -> 1.2 -> 1.1 roundtrip

Existing 1.1 components get statically converted to 1.2 during migration but should remain available as 1.1. In the proposed solution, this gets achieved by converting those components back from 1.2 to 1.1 on the fly, exactly like newly created (native 1.2) components. This does require that the conversion roundtrip via 1.2 should result in a component specification that is equivalent to the original. In other words, the following is required to hold:

d(u(c)) = c

where d=downgrade, u=upgrade and c is a native 1.1 component specification.

1.2 -> 1.1 -> 1.2 roundtrip

Pros

Pros of this solution

Cons

Cons of this solution

Centre impact

• Affected tools
• Impact on instances

Implementation examples

• Implementation on model level
• Implementation on instance level

Tickets

Tickets in the CMDI 1.2 milestone with the keyword keyword:

Ticket	Summary	Owner	Component	Priority	Status
No tickets found

Discussion

Discuss the topic in general below this point