This page is a subpage of CMDI 1.2

Migration of components from CMDI 1.1 to 1.2

The issue

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 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.

​Overview of implications for component migration of the various CMDI 1.2 specification topics

Implementation and application of the conversions

1.1 -> 1.2 conversion (upgrade)

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 (downgrade)

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 downgrading from 1.2 to 1.1 (for details, see ​tihs overview):

• 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 external 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

Here too, the schema location will not to be adjusted to point to the 1.1 counterpart of the schema.

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

Consider the following scenario (also see the diagram sketched below):

0. A new profile P gets created making use of some of the 1.2 features. Let's say that a mandatory attribute A is specified.
1. From this a profile P' can be derived: the dumbed down 1.1 version of profile P; In P' there is an optional attribute A', because 1.1 does not have mandatory attributes.
2. An instance I' gets generated on basis of profile P' and it happens to not provide a value for attribute A' - which is legal in P'
3. The data center that hosts I' decides to upgrade to 1.2 and upgrades the instance (see the page on instance migration), which leads to the generation of an instance I''
4. Note that I'' does not conform with P (as it does not have a value for attribute A) but rather with P'', which can be obtained by converting the CMDI 1.1 compliant P' back to CMDI 1.2

CMDI         1.1       1.2  
                     
Profile      P' <----- P              
                --------> P''         P != P''
             ^            ^
Instance     I'  -------> I''

This scenario makes it clear that dumbed down 1.2 compatible components and profiles should also be made available, i.e. the result of a conversion from 1.2 to 1.1 and back to 1.2. The Component Registry could have a special call for that, see the proposal below.

Component Registry REST service URLs

The Component Registry will expose profile specifications and their transformed derivatives on following URL's. The description reflect the state after the mass migration to 1.2 of all existing components and profiles. Profiles are being used in the example URL's but the exact same structure should exist for components.

• /rest/registry/profiles/{id}/1.2 returns the native (1.2) profile specification of the identified profile
• /rest/registry/profiles/{id}/1.2/xml returns the expanded version of the native profile specification of the identified profile
• /rest/registry/profiles/{id}/1.2/xsd returns the output of the comp2schema transformation (1.2 version) of the expanded profile profile

• /rest/registry/profiles/{id}/1.1 returns the output of the 1.2->1.1 transformation of the result of /rest/registry/profiles/{id}/1.2 (native spec)
• /rest/registry/profiles/{id}/1.1/xml returns the output of the 1.2->1.1 transformation of the result of /rest/registry/profiles/{id}/1.2/xml (expanded native spec)
• /rest/registry/profiles/{id}/1.1/xsd returns the output of the comp2schema transformation (1.1 version) of the result of /rest/registry/profiles/{id}/1.1/xml (converted expanded spec)

• /rest/registry/profiles/{id}/1.1/1.2 returns the output of the 1.1->1.2 transformation of the result of /rest/registry/profiles/{id}/1.1 (dumbed down spec)
• /rest/registry/profiles/{id}/1.1/1.2/xml returns the output of the 1.1->1.2 transformation of the result of /rest/registry/profiles/{id}/1.1/xml (dumbed down expanded spec)
• /rest/registry/profiles/{id}/1.1/1.2/xsd returns the output of the comp2schema transformation (1.2 version) of the result of /rest/registry/profiles/{id}/1.1/1.2/xml (re-upgraded expanded spec)

• /rest/registry/profiles/{id} is an alias for /rest/registry/profiles/{id}/1.1
• /rest/registry/profiles/{id}/xml is an alias for /rest/registry/profiles/{id}/1.1/xml
• /rest/registry/profiles/{id}/xsd is an alias for /rest/registry/profiles/{id}/1.1/xsd

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 componentmigration:

Ticket	Summary	Owner	Component	Priority	Status
No tickets found

Discussion

Oddrun: If d(u(c)) = c is to hold always, we need to ensure that 1.2 is a strict extension (or identical) to 1.1, not just "mostly an extension", as said above. But this is surely the case?

Twan: See ​this document for an assessment. It seems to be a safe assumption.