Home » Archived » M2M (model-to-model transformation) » [Announce] A Proposal and Prototype for an Eclipse Model Registry
| [Announce] A Proposal and Prototype for an Eclipse Model Registry [message #17559] |
Mon, 19 February 2007 21:32  |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
[Apologies for multiple postings. Please reply to the GMT newsgroup posting.]
Context
-------
A model transformation is declared:
e.g. in QVTrelation
transformation SeqToStm(seqDgm: SeqMM; stm: StmcMM)
the seqDgm model complying with the SeqMM meta-model is transformed to/from the stm model complying with the STmcMM meta-model.
Problem
-------
How are the (models and) meta-models located?
e.g. where is the definition that
SeqMM ==> platform:/resource/QvtrTestFiles/ModelMorfExamples/SeqToStm/ SeqMM.xml
[assuming that there is no entry in the EMF package registry, since SeqMM.xml is a user artefact for which no plugin has been built
and installed as an Ecore model.]
Analysis
--------
The above example happens to be a line from a QVTrelation example from ModelMorf.
I have seen the same problem with ATL, MOFscript and Tefkat, and presume that it exists for all tools that exploit meta-models.
I have seen some rather poor solutions to this problem that are barely adequate for application of transformations and difficult to
generalise across tools.
I am writing a QVTrelation context sensitive editor, and so the editor needs to resolve the meta-models in order to perform
meta-model compliance validation. Use of solutions specific to application of transformations will not suffice. It must be possible
to double click the QVTrelation source to open the editor, and it is not acceptable to modify the source file in order to include
the platform-specific meta-model bindings.
Solution
--------
A user configurable registry of 'model accessor' to 'platform resource' is required, where 'model accessor' can be an informal model
name, such as 'SeqMM' or a URI such as 'http:/my/seq/mm', and platform resource is a simple URI such as
'file:/C:/My/seq/metamodel.xml' or an installed Eclipse resource such as 'platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore'
The Proposed Eclipse Model Registry (currently available as a prototype from the GMT UMLX Update site
http://download.eclipse.org/technology/gmt/umlx/updates
or CVS at org.eclipse.gmt/umlx/plugins/org.eclipse.gmt.umlx.registry on /cvsroot/technology)
maintains a ModelRegistry model in 'project'/.settings/org.eclipse.gmt.umlx.registry.modelregis try
with per-resource bindings of model accessor to platform resource. Resolution of these bindings is hierarchical, so a binding for a
file, applies only to a file, whereas a binding to a folder applies to all files within the folder and sub-folder, and a binding to
a project applies throughout the project.
Once the Model Registry Nature is added to a project (via the right button menu on a project), resources within the project acquire
Model Registry Property Page (via the Properties selection on the right button menu on the resource). The Model Registry Property
Page provides a GUI for defining the 'model accessor' to 'platform resource' bindings.
The binding also includes a serialisation type, which may be defined to something other than XML to allow non-XML models (e.g. KM3)
to be bound.
Tool support
------------
In order to exploit this registry tools should construct a ModelResourceResolver for the IResource (file) for which resources are to
be resolved, optionally specifying a ResourceSet to be used during resolution.
String metaId = ...; // model for resolution
IResource file = ...; // context for resolution
ResourceSet resourceSet = new ResourceSetImpl(); // or EcoreFamilyResourceSetImpl()
ModelResourceResolver resolver = new ModelResourceResolver(file, resourceSet);
URI uri = resolver.getURI(modelId); // Get platform resource URI or null
Resource resource = resolver.getResource(uri, true); // Same API as ResourceSet.getResource()
EMOF Support
------------
EMF currently allows EMOF models to be used in place of Ecore models, provided the file extension of the EMOF models is distinct and
provided that the EMOFResourceFactoryImpl has been registered for those extensions with the extension to factory map
(resourceSet.getResourceFactoryRegistry().getExtensionToFact oryMap()).
If EcoreFamilyResourceSetImpl is used in place of ResourceSetImpl, the URI of the namespace of the root XML element is examined and
an appropriate content dependent ResourceFactory is used to load the XML file. EMOF and Ecore models can then be used
interchangeably regardless of file extension.
Extension point hooks
---------------------
The model_accessor extension point defines, the kinds of keys for accessing the model registry. By default ModelName and URI keys
are provided. Additional keys may be defined.
The model_content extension point defines the mapping from the URI of the namespace of an XML element to the Resource.Factory that
supports that XML model format. By default Ecore and EMOF are supported. Other XML formats may be defined.
The model_serialisation extension point defines the mapping from non-XML serialisations of a model and the Resource.Factory that
converts that serialisation to/from Ecore. Only the default XML serialisation is supported by default.
Summary
-------
This proposal and prototype is intended to be entirely generic; it has no UMLX-specific functionality.
It is hoped that tools will experiment with it, so that the API can be validated and in due course the prototype migrate to become
part of EMF.
The code was developed using JDK 1.6.0 and Eclipse 3.3M4. It requires at least J2SE1.5, and appears to work on Eclipse 3.2.1. The
Model Registry pages appear to work only for folders and files on Eclipse 3.2.
Comments and Feedback very welcome.
Regards
Ed Willink
|
|
|
| Re: [Announce] A Proposal and Prototype for an Eclipse Model Registry [message #486934 is a reply to message #17559] |
Mon, 21 September 2009 08:43  |
Francisco Javier Cano
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Hello,
I have seen the proposal for this component at
http://www.eclipse.org/proposals/emf-registry/
how do I add myself as an interested party?
Regards,
Javi
--
Ed Willink wrote:
> [Apologies for multiple postings. Please reply to the GMT newsgroup
> posting.]
>
> Context
> -------
>
> A model transformation is declared:
>
> e.g. in QVTrelation
>
> transformation SeqToStm(seqDgm: SeqMM; stm: StmcMM)
>
> the seqDgm model complying with the SeqMM meta-model is transformed
> to/from the stm model complying with the STmcMM meta-model.
>
> Problem
> -------
>
> How are the (models and) meta-models located?
>
> e.g. where is the definition that
>
> SeqMM ==>
> platform:/resource/QvtrTestFiles/ModelMorfExamples/SeqToStm/ SeqMM.xml
>
> [assuming that there is no entry in the EMF package registry, since
> SeqMM.xml is a user artefact for which no plugin has been built and
> installed as an Ecore model.]
>
> Analysis
> --------
>
> The above example happens to be a line from a QVTrelation example from
> ModelMorf.
>
> I have seen the same problem with ATL, MOFscript and Tefkat, and presume
> that it exists for all tools that exploit meta-models.
>
> I have seen some rather poor solutions to this problem that are barely
> adequate for application of transformations and difficult to generalise
> across tools.
>
> I am writing a QVTrelation context sensitive editor, and so the editor
> needs to resolve the meta-models in order to perform meta-model
> compliance validation. Use of solutions specific to application of
> transformations will not suffice. It must be possible to double click
> the QVTrelation source to open the editor, and it is not acceptable to
> modify the source file in order to include the platform-specific
> meta-model bindings.
>
> Solution
> --------
>
> A user configurable registry of 'model accessor' to 'platform resource'
> is required, where 'model accessor' can be an informal model name, such
> as 'SeqMM' or a URI such as 'http:/my/seq/mm', and platform resource is
> a simple URI such as 'file:/C:/My/seq/metamodel.xml' or an installed
> Eclipse resource such as
> 'platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore'
>
> The Proposed Eclipse Model Registry (currently available as a prototype
> from the GMT UMLX Update site
> http://download.eclipse.org/technology/gmt/umlx/updates
> or CVS at org.eclipse.gmt/umlx/plugins/org.eclipse.gmt.umlx.registry on
> /cvsroot/technology)
> maintains a ModelRegistry model in
> 'project'/.settings/org.eclipse.gmt.umlx.registry.modelregis try
> with per-resource bindings of model accessor to platform resource.
> Resolution of these bindings is hierarchical, so a binding for a file,
> applies only to a file, whereas a binding to a folder applies to all
> files within the folder and sub-folder, and a binding to a project
> applies throughout the project.
>
> Once the Model Registry Nature is added to a project (via the right
> button menu on a project), resources within the project acquire Model
> Registry Property Page (via the Properties selection on the right button
> menu on the resource). The Model Registry Property Page provides a GUI
> for defining the 'model accessor' to 'platform resource' bindings.
>
> The binding also includes a serialisation type, which may be defined to
> something other than XML to allow non-XML models (e.g. KM3) to be bound.
>
> Tool support
> ------------
>
> In order to exploit this registry tools should construct a
> ModelResourceResolver for the IResource (file) for which resources are
> to be resolved, optionally specifying a ResourceSet to be used during
> resolution.
>
> String metaId = ...; // model for resolution
> IResource file = ...; // context for resolution
> ResourceSet resourceSet = new ResourceSetImpl(); // or
> EcoreFamilyResourceSetImpl()
> ModelResourceResolver resolver = new ModelResourceResolver(file,
> resourceSet);
> URI uri = resolver.getURI(modelId); // Get platform
> resource URI or null
> Resource resource = resolver.getResource(uri, true); // Same API
> as ResourceSet.getResource()
>
> EMOF Support
> ------------
>
> EMF currently allows EMOF models to be used in place of Ecore models,
> provided the file extension of the EMOF models is distinct and provided
> that the EMOFResourceFactoryImpl has been registered for those
> extensions with the extension to factory map
> (resourceSet.getResourceFactoryRegistry().getExtensionToFact oryMap()).
>
> If EcoreFamilyResourceSetImpl is used in place of ResourceSetImpl, the
> URI of the namespace of the root XML element is examined and an
> appropriate content dependent ResourceFactory is used to load the XML
> file. EMOF and Ecore models can then be used interchangeably regardless
> of file extension.
>
> Extension point hooks
> ---------------------
>
> The model_accessor extension point defines, the kinds of keys for
> accessing the model registry. By default ModelName and URI keys are
> provided. Additional keys may be defined.
>
> The model_content extension point defines the mapping from the URI of
> the namespace of an XML element to the Resource.Factory that supports
> that XML model format. By default Ecore and EMOF are supported. Other
> XML formats may be defined.
>
> The model_serialisation extension point defines the mapping from non-XML
> serialisations of a model and the Resource.Factory that converts that
> serialisation to/from Ecore. Only the default XML serialisation is
> supported by default.
>
> Summary
> -------
>
> This proposal and prototype is intended to be entirely generic; it has
> no UMLX-specific functionality.
>
> It is hoped that tools will experiment with it, so that the API can be
> validated and in due course the prototype migrate to become part of EMF.
>
> The code was developed using JDK 1.6.0 and Eclipse 3.3M4. It requires at
> least J2SE1.5, and appears to work on Eclipse 3.2.1. The Model Registry
> pages appear to work only for folders and files on Eclipse 3.2.
>
> Comments and Feedback very welcome.
>
> Regards
>
> Ed Willink
>
|
|
|
| Re: [Announce] A Proposal and Prototype for an Eclipse Model Registry [message #487396 is a reply to message #486934] |
Wed, 23 September 2009 05:51 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Francisco
The proposal is not supposed to be visible or linked to.
The proposal has been withdrawn because creation of an Incubation
project used by a mature project such as MDT/OCL would be anomalous.
The model registry will therefore be provided as part of MDT/OCL for the
Helios release.
Please use the MDT/OCL newsgroup to express your interest. (Thank you
in advance.)
A prototype is available (most conveniently from CVS) as part of the
M2M/QVT Declarative project. The OCL migration will involve a number
of package and path name changes.
Regards
Ed Willink
Francisco Javier Cano wrote:
> Hello,
>
> I have seen the proposal for this component at
> http://www.eclipse.org/proposals/emf-registry/
>
> how do I add myself as an interested party?
>
> Regards,
> Javi
> --
>
> Ed Willink wrote:
>> [Apologies for multiple postings. Please reply to the GMT newsgroup
>> posting.]
>>
>> Context
>> -------
>>
>> A model transformation is declared:
>>
>> e.g. in QVTrelation
>>
>> transformation SeqToStm(seqDgm: SeqMM; stm: StmcMM)
>>
>> the seqDgm model complying with the SeqMM meta-model is transformed
>> to/from the stm model complying with the STmcMM meta-model.
>>
>> Problem
>> -------
>>
>> How are the (models and) meta-models located?
>>
>> e.g. where is the definition that
>>
>> SeqMM ==>
>> platform:/resource/QvtrTestFiles/ModelMorfExamples/SeqToStm/ SeqMM.xml
>>
>> [assuming that there is no entry in the EMF package registry, since
>> SeqMM.xml is a user artefact for which no plugin has been built and
>> installed as an Ecore model.]
>>
>> Analysis
>> --------
>>
>> The above example happens to be a line from a QVTrelation example from
>> ModelMorf.
>>
>> I have seen the same problem with ATL, MOFscript and Tefkat, and
>> presume that it exists for all tools that exploit meta-models.
>>
>> I have seen some rather poor solutions to this problem that are barely
>> adequate for application of transformations and difficult to
>> generalise across tools.
>>
>> I am writing a QVTrelation context sensitive editor, and so the editor
>> needs to resolve the meta-models in order to perform meta-model
>> compliance validation. Use of solutions specific to application of
>> transformations will not suffice. It must be possible to double click
>> the QVTrelation source to open the editor, and it is not acceptable to
>> modify the source file in order to include the platform-specific
>> meta-model bindings.
>>
>> Solution
>> --------
>>
>> A user configurable registry of 'model accessor' to 'platform
>> resource' is required, where 'model accessor' can be an informal model
>> name, such as 'SeqMM' or a URI such as 'http:/my/seq/mm', and platform
>> resource is a simple URI such as 'file:/C:/My/seq/metamodel.xml' or an
>> installed Eclipse resource such as
>> 'platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore'
>>
>> The Proposed Eclipse Model Registry (currently available as a
>> prototype from the GMT UMLX Update site
>> http://download.eclipse.org/technology/gmt/umlx/updates
>> or CVS at org.eclipse.gmt/umlx/plugins/org.eclipse.gmt.umlx.registry
>> on /cvsroot/technology)
>> maintains a ModelRegistry model in
>> 'project'/.settings/org.eclipse.gmt.umlx.registry.modelregis try
>> with per-resource bindings of model accessor to platform resource.
>> Resolution of these bindings is hierarchical, so a binding for a file,
>> applies only to a file, whereas a binding to a folder applies to all
>> files within the folder and sub-folder, and a binding to a project
>> applies throughout the project.
>>
>> Once the Model Registry Nature is added to a project (via the right
>> button menu on a project), resources within the project acquire Model
>> Registry Property Page (via the Properties selection on the right
>> button menu on the resource). The Model Registry Property Page
>> provides a GUI for defining the 'model accessor' to 'platform
>> resource' bindings.
>>
>> The binding also includes a serialisation type, which may be defined
>> to something other than XML to allow non-XML models (e.g. KM3) to be
>> bound.
>>
>> Tool support
>> ------------
>>
>> In order to exploit this registry tools should construct a
>> ModelResourceResolver for the IResource (file) for which resources are
>> to be resolved, optionally specifying a ResourceSet to be used during
>> resolution.
>>
>> String metaId = ...; // model for resolution
>> IResource file = ...; // context for
>> resolution
>> ResourceSet resourceSet = new ResourceSetImpl(); // or
>> EcoreFamilyResourceSetImpl()
>> ModelResourceResolver resolver = new ModelResourceResolver(file,
>> resourceSet);
>> URI uri = resolver.getURI(modelId); // Get platform
>> resource URI or null
>> Resource resource = resolver.getResource(uri, true); // Same
>> API as ResourceSet.getResource()
>>
>> EMOF Support
>> ------------
>>
>> EMF currently allows EMOF models to be used in place of Ecore models,
>> provided the file extension of the EMOF models is distinct and
>> provided that the EMOFResourceFactoryImpl has been registered for
>> those extensions with the extension to factory map
>> (resourceSet.getResourceFactoryRegistry().getExtensionToFact oryMap()).
>>
>> If EcoreFamilyResourceSetImpl is used in place of ResourceSetImpl, the
>> URI of the namespace of the root XML element is examined and an
>> appropriate content dependent ResourceFactory is used to load the XML
>> file. EMOF and Ecore models can then be used interchangeably
>> regardless of file extension.
>>
>> Extension point hooks
>> ---------------------
>>
>> The model_accessor extension point defines, the kinds of keys for
>> accessing the model registry. By default ModelName and URI keys are
>> provided. Additional keys may be defined.
>>
>> The model_content extension point defines the mapping from the URI of
>> the namespace of an XML element to the Resource.Factory that supports
>> that XML model format. By default Ecore and EMOF are supported. Other
>> XML formats may be defined.
>>
>> The model_serialisation extension point defines the mapping from
>> non-XML serialisations of a model and the Resource.Factory that
>> converts that serialisation to/from Ecore. Only the default XML
>> serialisation is supported by default.
>>
>> Summary
>> -------
>>
>> This proposal and prototype is intended to be entirely generic; it has
>> no UMLX-specific functionality.
>>
>> It is hoped that tools will experiment with it, so that the API can be
>> validated and in due course the prototype migrate to become part of EMF.
>>
>> The code was developed using JDK 1.6.0 and Eclipse 3.3M4. It requires
>> at least J2SE1.5, and appears to work on Eclipse 3.2.1. The Model
>> Registry pages appear to work only for folders and files on Eclipse 3.2.
>>
>> Comments and Feedback very welcome.
>>
>> Regards
>>
>> Ed Willink
>>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:44:22 GMT 2024
Powered by FUDForum. Page generated in 0.02797 seconds |
] 
Search
Help
Register
Login
Home
