Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Design information on Ecore2Ecore, Ecore2XML(Help to understand intention, Code read pointers)
Design information on Ecore2Ecore, Ecore2XML [message #1857675] Tue, 21 February 2023 01:02
Jörn Guy Süß is currently offline Jörn Guy SüßFriend
Messages: 320
Registered: July 2009
Location: Anstead, Brisbane, Queens...
Senior Member

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.



Previous Topic:EMF Forms evaluation
Next Topic:[EMF FORMS] View no content update
Goto Forum:
  


Current Time: Thu Mar 28 21:36:43 GMT 2024

Powered by FUDForum. Page generated in 0.02955 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top