Changes between Version 12 and Version 13 of CMDI 1.2/Migration/Component migration

Timestamp:

02/04/14 09:18:44 (10 years ago)

Author:

twagoo

Comment:

link to assessment document

CMDI 1.2/Migration/Component migration

@@ -12 +12 @@
 
 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.
+
+[https://docs.google.com/spreadsheet/ccc?key=0Avyg_78eBoF4dEJUOXVjVHZSZXE0cnJQSTdrUXVvaGc&usp=sharing Overview of implications for component migration of the various CMDI 1.2 specification topics]
 
 === Implementation and application of the conversions ===
@@ -112 +114 @@
 == 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?
+'''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 [https://docs.google.com/spreadsheet/ccc?key=0Avyg_78eBoF4dEJUOXVjVHZSZXE0cnJQSTdrUXVvaGc&usp=sharing this document] for an assessment. It seems to be a safe assumption.