Design information on Ecore2Ecore, Ecore2XML [message #1857675] |
Tue, 21 February 2023 01:02 |
|
Hello!
I am trying to review the built-in mechanisms of EMF and have come across the Ecore2Ecore and Ecore2XML mapping facilities,
Both ship with EMF in every release and are, as far as I can understand, an early mechanism for model transformation and migration.
I would like to document them for myself and others. For that I would like some pointers to code-read, if that is required. I have not been able to get a lot out of the underlying metamodels and the editors do not have help systems.
My understanding so far is:
- Ecore2Ecore
- a conceptual tool used primarily for documenting transforms.
- has a notion of instance mapping and type mapping
- mappings can be nested.
- has two concrete mapping roots: from Ecore or from XSD.
- mappings are M:N (inputs:outputs)
- The root has a command stack, which is a string - no idea why. Cold be that this model was once intended to be used during execution of a mapping engine?
- Outputs can be marked as read only, meaning that a mapping is non-reversible?
- Direction can be marked as topToBottom, presumably some rule application order?
- Ecore2Ecore can be transformed to Ecore2XML. Only 1:1 and 0:1 can be considered, as that mapping is structural
- Ecore2XML
- a tool for mapping Ecore 2 XML notation
- notation is a flat map.
- Can be used to create XML notation valid as XMI for new Ecore
- Can be registered in a global registry to be considered on any serialisation, even via extension point
- XMLResource will consult this if prompted via an OPTION_EXTENDED_META_DATA.
- XMLResource will read the input in the old format, but store in the new format, considering the mapping.
- This performs data migration implicitly.
- OPTION_RECORD_UNKNOWN_FEATURE can be used to send out unknown features as they came in.
- OPTION_RESOURCE_HANDLER can be used for programmatic call-backs to perform non-standard reads.
|
|
|
Powered by
FUDForum. Page generated in 0.01708 seconds