This page is a subpage of CMDI 1.2
Tool aspects of CMDI version migration
On this page, tool aspects of the migration from CMDI 1.1 to CMDI 1.2 can be collected. Please extend this page with affected tools that you are responsible for or aware of!
Component Registry
A mass migration will be carried out to all components and profile in the Component Registry. From that point on, it will perform on the fly conversion; see Component Registry REST service URL's.
VLO
The VLO will have to support both CMDI 1.1 and 1.2. Since VLO is read-only, the importer could internally rely on 1.2, convert all 1.1 instances in a pre-processing stage.
Namespace should not be an issue,as "VTD-XML (since v 2.9) fully conforms to XML Namespace 1.0 spec" (according to the FAQ)
Arbil
Arbil will probably have to support both CMDI 1.1 and 1.2, both read and write. Handling of namespaces will have to be looked at carefully. Since Arbil was designed to handle arbitrary schema based XML documents, a large part of the functionality for 1.1 and 1.2 could be shared, but different 'hooks' will have to be implemented for both versions.
Arbil could be used as a tool to migrate with the planned transformation feature (basically executing arbitrary/predefined XSLT's on local metadata documents).
COALA
Florian Schiel wrote:
The following 1.2 tickets (2014-02-25) will affect COALA code: #146 #236 #403 + some minor things as version attribute etc.; migration the code from 1.1 to 1.2 should not be any problem for COALA
Proforma
Thorsten Tripple wrote:
- As soon as I build in CMDI 1.2 support I would make it impossible to
create new CMDI 1.1 files. ProFormA users would be way too unaware of the versions. I would leave the current state somewhere for emergency cases, but else would not.
- If I can get hold of a generic CMDI 1.1 to CMDI 1.2 converter, I
would add this converter for editing purposes. Else editing version 1.1 will support the "old" ProFormA only.
- I will definitively not support a CMDI 1.2 to 1.1 backwards
converter. Or edit 1.2 and save 1.1 .
All implementations I know of using ProFormA will parse against the schema retrieved from the component registry, so as long as the component registry supplies a 1.2 schema, I don't see a problem for the repositories I work with.
SMC Browser
Using the 1.1 to 1.2 upgrade XSLT SMC Browser can fully switch to CMDI 1.2 internally. The browser is moving to work on general graph-type data, which mean that CMDI 1.2 is just one of the possible input formats.
WebLicht
WebLicht doesn't need any of the CMDI 1.2-only features, so the existing profile won't change. If any instances are delivered in 1.2 downgrading to 1.1 is one simple XSLT away.
Meertens Search Engine
Marc Kemps-Snijders wrote:
We are currently reworking the CMDI search engine and as far as I can tell the changes should not affect the indexing process. I will still need to asses whether the current instance also remains unaffected but we should be able to switch there as well once implementation has completed.
Discussion
Discuss the topic in general below this point
