Home » Modeling » Modeling (top-level project) » Is Ecore fit for EMOF meta-modeling?
| Is Ecore fit for EMOF meta-modeling? [message #377176] |
Tue, 06 June 2006 19:04  |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
I have recently encountered some nasty problems when trying to use Ecore as
the underlying technology for QVT and consequently EMOF-based modeling.
The problem is that QVT is based on EMOF and so defined in EMOF and so
at some meta-meta-... level the model must be EMOF.
Ecore is effective as a generator of executable Java models, for which
at some meta-meta-... level the model is Ecore.
Now if QVT is modeled using EMF, it is possible to register QVT as an
Ecore package and to have a consistent model that uses EMOF. However a QVT
transformation applied to a QVT model must be able to access the QVT meta-model,
and that meta-model is Ecore not EMOF, so unless EMF provides an ability to
access (rather than just serialise) a registered Ecore model as EMOF, it is not possible
to traverse the meta-levels of QVT without crossing from EMOF to Ecore and
getting type violations. https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239.
We seem to have 2 choices, either every EMOF derived model must acquire a
an E counterpart. We already have (E)OCL, but we will need EQVT etc, etc, etc.
Or we recognise that EMOF-based modeling should be EMOF-based.
The latter means that resolution of the QVT URI must be able to resolve to
qvt.emof.
A closely related problem that I have observed with OMELET, Tefkat, ATL and
MOFScript, is how to convert a meta-model-name into a model-model-content.
The EMF Package registry provides a partial solution, using a URI as a
meta-model-name, but it only works for meta-models
that have been successfuly converted to Java code. This is not possible for
unmodified EMOF models, since nsURI and instanceClassName nulls cause NPEs in
genmodel, and anyway, why is it necessary to generate Java code when none is wanted?
It seems that the EMF Package registry should have two forms of registration:
URI => implementing Java class, genModel file name
URI => emofModel file name
so that the latter can be consistently used for EMOF-based meta-modelling, and the former
for Java-based executables. The emofModel could be auto-generated by genModel for Java-based
models.
We just need an ability to register emofModels in plugin.xml. To avoid the
inconvenience of starting up nested Eclipse sessions, we need a registered package
browser that supports maintenance and loading of perhaps a .metamodels file per
project.
Regards
Ed Willink
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #377179 is a reply to message #377176] |
Tue, 06 June 2006 19:18  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Willink wrote:
> I have recently encountered some nasty problems when trying to use
> Ecore as
> the underlying technology for QVT and consequently EMOF-based modeling.
>
> The problem is that QVT is based on EMOF and so defined in EMOF and so
> at some meta-meta-... level the model must be EMOF.
What does that mean though? Ecore can be serialized as EMOF and can be
deserialized from EMOF.
>
> Ecore is effective as a generator of executable Java models, for which
> at some meta-meta-... level the model is Ecore.
That's one of the things it's for but given that it supports dynamic
model instances for which no code is ever generated, that's not the only
thing it's for.
>
> Now if QVT is modeled using EMF, it is possible to register QVT as an
> Ecore package and to have a consistent model that uses EMOF. However a
> QVT
> transformation applied to a QVT model must be able to access the QVT
> meta-model,
> and that meta-model is Ecore not EMOF, so unless EMF provides an
> ability to
> access (rather than just serialise) a registered Ecore model as EMOF,
> it is not possible
> to traverse the meta-levels of QVT without crossing from EMOF to Ecore
> and
> getting type violations.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239.
Again, what does this mean? EMOF's Java realization is not well
specified so I would argue that Ecore's API is the EMOF's Java realization.
>
> We seem to have 2 choices, either every EMOF derived model must acquire a
> an E counterpart. We already have (E)OCL, but we will need EQVT etc,
> etc, etc.
What does EMOF have that isn't already in the Ecore API?
>
> Or we recognise that EMOF-based modeling should be EMOF-based.
And that would imply what additional things that aren't already there in
Ecore today?
>
> The latter means that resolution of the QVT URI must be able to
> resolve to
> qvt.emof.
>
> A closely related problem that I have observed with OMELET, Tefkat,
> ATL and
> MOFScript, is how to convert a meta-model-name into a
> model-model-content.
>
> The EMF Package registry provides a partial solution, using a URI as a
> meta-model-name, but it only works for meta-models
> that have been successfuly converted to Java code. This is not
> possible for
> unmodified EMOF models, since nsURI and instanceClassName nulls cause
> NPEs in
> genmodel, and anyway, why is it necessary to generate Java code when
> none is wanted?
This seems to be a misunderstanding. The packages registered in the
EPackage.Registry.INSTANCE need not correspond to generated packages
only. Also, the instanceClassName is an issue only for EDataTypes and
in that case the class is needed as much to support a dynamic instances
as it is to generate Java code.
>
> It seems that the EMF Package registry should have two forms of
> registration:
> URI => implementing Java class, genModel file name
> URI => emofModel file name
> so that the latter can be consistently used for EMOF-based
> meta-modelling, and the former
> for Java-based executables. The emofModel could be auto-generated by
> genModel for Java-based
> models.
Anyone needing to register models that aren't ever generated could add
such an extension point. We could add one to EMF in the next release if
this would be useful in general (though not generating a model
statically but still registering it statically seems kind of odd).
>
> We just need an ability to register emofModels in plugin.xml. To avoid
> the
> inconvenience of starting up nested Eclipse sessions, we need a
> registered package
> browser that supports maintenance and loading of perhaps a .metamodels
> file per
> project.
I could imagine the extension point being just like generated_packages,
but would specify the URI of the .ecore/.emof serialization rather than
the name of the implementing package class.
>
> Regards
>
> Ed Willink
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Is Ecore fit for EMOF meta-modeling? [message #377184 is a reply to message #377182] |
Thu, 08 June 2006 19:54 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000005080506010208010703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
I'm a bit confused. I particularly don't understand this part:
The problem is that the transformation model refers to the QVT model
by its URI, and EMF is currently only able to resolve this by
supplying the Java
support which is an Ecore(emof:Package).
I understand why a logical URI might be used to refer to a model and for
that EMF's resource set's URI converter provides for URI mappings to
redirect a logical URI to a physical URI. This could be used to map an
emof:Package's URI to a resource containing an actual emof:Package
instance. But in 145239
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239> that's not what
you seem to be doing. You seem to using the nsURI of a generated
ecore:EPackage to refer to what you expect will be an emof:Package. So
it seems to me that the generated ecore:EPackage should not have an
nsURI that collides with the logical URI of an emof:Package instance
since it results in an ambiguity as to whether the URI should refer to
an Ecore model or an EMOF model...
Even in the case of such ambiguity, you could specialize a
ResourceSetImpl's
protected Resource delegatedGetResource(URI uri, boolean loadOnDemand)
{
EPackage ePackage =
getPackageRegistry().getEPackage(uri.toString());
return ePackage == null ? null : ePackage.eResource();
}
to redirect logical emof:Package URIs to an EMOF package registry
instead of the default ecore:EPackage registry.
Ed Willink wrote:
> Hi Ed
>
> To avoid unnecessary confusions, I'll refrain from commenting about
> solutions until we're agreed on the problem.
>
> And to avoid a further confusion, let me make it clear that I think
> EMF offers very powerful facilities with a helpful API for managing
> models
> within a Java context.
>
> My comments are entirely directed to problems that arise once meta-models
> are used in a more general sense. Hence my posting to this rather than
> the
> EMF newsgroup.
>
> Let me introduce a little notation.
>
> EMOF(x) represents the modeled type of x in EMOF.
> Ecore(x) represents the modeled type of x in Ecore.
>
> Thus EMOF(emof:Package) is emof:Package.
> and Ecore(emof:Package) is ecore:EPackage.
>
> The QVT packages extend the EMOF packages and includes references to
> its own types.
>
> Thus a
>
> qvtbase:TypedModel.usedPackage is an ecore:Package.
>
> so a model conforming to the QVT meta-model may have a
> qvtbase:TypedModel element.
> If this model is a transformation model that transforming QVT models
> we may have
> a qvtbase:TypedModel element that refers to the emof:Package
> describing the emof:Package.
>
> This can work fine so long as EMOF is modelled by EMOF.
>
> However it doesn't work when EMOF is modelled by Ecore.
>
> The problem is that the transformation model refers to the QVT model
> by its
> URI, and EMF is currently only able to resolve this by supplying the Java
> support which is an Ecore(emof:Package). Consequently when the Sample
> Ecore
> Editor attempts to peruse the model it fails because it finds it has an
> EPackage (Ecore(emof:Package)) when the meta-model requires an
> ecore:Package.
>
> EMF has useful for support for EMOF at its external interfaces, but
> has no
> support for EMOF internally. The meta-modelling/transformation
> perspective in
> which the types of models are traversed more deeply exposes this
> limitation.
>
> A modeling technique XXX for xxx must ensure that
>
> XXX(xxx:Package) is (not incompatible with) xxx:Package
>
> Regards
>
> Ed Willink
>
--------------000005080506010208010703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
I'm a bit confused. I particularly don't understand this part:<br>
<blockquote>The problem is that the transformation model refers to the
QVT model by its
URI, and EMF is currently only able to resolve this by supplying the
Java
<br>
support which is an Ecore(emof:Package).<br>
</blockquote>
I understand why a logical URI might be used to refer to a model and
for that EMF's resource set's URI converter provides for URI mappings
to redirect a logical URI to a physical URI. This could be used to map
an emof:Package's URI to a resource containing an actual emof:Package
instance. But in <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239">145239</a>
that's not what you seem to be doing. You seem to using the nsURI of a
generated ecore:EPackage to refer to what you expect will be an
emof:Package. So it seems to me that the generated ecore:EPackage
should not have an nsURI that collides with the logical URI of an
emof:Package instance since it results in an ambiguity as to whether
the URI should refer to an Ecore model or an EMOF model...<br>
<br>
Even in the case of such ambiguity, you could specialize a
ResourceSetImpl's <br>
<blockquote> protected Resource delegatedGetResource(URI uri, boolean
loadOnDemand)<br>
{<br>
EPackage ePackage =
getPackageRegistry().getEPackage(uri.toString());<br>
return ePackage == null ? null : ePackage.eResource();<br>
}<br>
</blockquote>
to redirect logical emof:Package URIs to an EMOF package registry
instead of the default ecore:EPackage registry.<br>
<br>
<br>
Ed Willink wrote:
<blockquote cite="mide69q1n$lkk$1@utils.eclipse.org" type="cite">Hi Ed
<br>
<br>
To avoid unnecessary confusions, I'll refrain from commenting about
<br>
solutions until we're agreed on the problem.
<br>
<br>
And to avoid a further confusion, let me make it clear that I think
<br>
EMF offers very powerful facilities with a helpful API for managing
models
<br>
within a Java context.
<br>
<br>
My comments are entirely directed to problems that arise once
meta-models
<br>
are used in a more general sense. Hence my posting to this rather than
the
<br>
EMF newsgroup.
<br>
<br>
Let me introduce a little notation.
<br>
<br>
EMOF(x) represents the modeled type of x in EMOF.
<br>
Ecore(x) represents the modeled type of x in Ecore.
<br>
<br>
Thus EMOF(emof:Package) is emof:Package.
<br>
and Ecore(emof:Package) is ecore:EPackage.
<br>
<br>
The QVT packages extend the EMOF packages and includes references to
its own types.
<br>
<br>
Thus a
<br>
<br>
qvtbase:TypedModel.u sedPackage is an ecore:Package.
<br>
<br>
so a model conforming to the QVT meta-model may have a
qvtbase:TypedModel element.
<br>
If this model is a transformation model that transforming QVT models we
may have
<br>
a qvtbase:TypedModel element that refers to the emof:Package describing
the emof:Package.
<br>
<br>
This can work fine so long as EMOF is modelled by EMOF.
<br>
<br>
However it doesn't work when EMOF is modelled by Ecore.
<br>
<br>
The problem is that the transformation model refers to the QVT model by
its
<br>
URI, and EMF is currently only able to resolve this by supplying the
Java
<br>
support which is an Ecore(emof:Package). Consequently when the Sample
Ecore
<br>
Editor attempts to peruse the model it fails because it finds it has an
<br>
EPackage (Ecore(emof:Package)) when the meta-model requires an
ecore:Package.
<br>
<br>
EMF has useful for support for EMOF at its external interfaces, but has
no
<br>
support for EMOF internally. The meta-modelling/transformation
perspective in
<br>
which the types of models are traversed more deeply exposes this
limitation.
<br>
<br>
A modeling technique XXX for xxx must ensure that
<br>
<br>
XXX(xxx:Package) is (not incompatible with) xxx:Package
<br>
<br>
Regards
<br>
<br>
Ed Willink
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------000005080506010208010703--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #377204 is a reply to message #377184] |
Fri, 09 June 2006 19:31 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
> Ed Merks wrote
> it seems to me that the generated ecore:EPackage should not have an
> nsURI that collides with the logical URI of an emof:Package instance
> since it results in an ambiguity as to whether the URI should refer to
> an Ecore model or an EMOF model...
This is a different way of making precisely my point. There must not be
an ambiguity. In fact, see later, it is not possible to register an EMOF
model and for it to remain an EMOF model.
> Even in the case of such ambiguity, you could specialize a
> ResourceSetImpl's
No I can't. I am trying to constrain this discussion to the more abstract
perspective of consistent use of models within the Eclipse/EMF context. I am
discussing properties that the standard (Java) code should exhibit not ones
that my specialised application might introduce as a workaround.
The problem showed up in the Sample Ecore Model Editor, which despite its title
I (?mis-)interpret as Generic Model content viewer/editor.
Some models are Ecore (i.e EPackage, EClass etc) - Ecore, OCL, UML2
but the international standards are EMOF, OCL, UML2, QVT, .... and we must
expect that further standards will be EMOF-based rather than Ecore-based.
EMF currently resolves the ambiguity by requiring that standards are re-engineered
to use EClass rather than Class. This is very undesirable. It would be better
if EMOF and Ecore could co-exist seamlessly, with Ecore providing an effective
implementation for an EMOF specification.
EMF has resolved two EMOF/Ecore incompatibilities by providing the ability to
read/write EMOF or Ecore at will.
I have unfortunately uncovered a third incompatibility with regard to the use
of a model and consequently to use EMOF or Ecore at will.
An XMI serialisation of a model defines its model elements using xsi:type and
XML namespaces.
<?xml version="1.0" encoding="UTF-8"?>
<qvtrelation:RelationalTransformation xmlns:qvtrelation="http:///qvtrelation.ecore"
...
<modelParameter usedPackage="http:///qvttemplate.ecore#/" ...
This is:
XMIelement[tag='anon' type=qvtrelation:RelationalTransformation]
XMIelement[tag=modelParameter type=qvtbase:TypedModel]
XMIreference[tag=usedPackage type=emof:Package value="http:///qvttemplate.ecore#/"]
(the first type is explicit, the latter two are implicit from the schema).
I understand the XMIreference to mean at least 'resolve the value from the root element
of the URI "http:///qvttemplate.ecore" and expect its type to be emof:Package'.
Confusingly for the purposes of this discussion, the ".ecore" in the URI indicates
the technology that the author of the qvttemplate model used, so the URI appears
to indicate Ecore. It doesn't it is just a longer name.
In order for EMF to resolve a URI, a Java class must be registered. The resolution
yields an EPackage for the root of qvttemplate.ecore which is in fact
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="qvttemplate"
nsURI="http:///qvttemplate.ecore" nsPrefix="qvttemplate">
this EPackage describes an ecore:EPackage named qvttemplate, not an emof:Package
so the expectation that the URI root element is an emof:Package is not satisfied,
and in the case of the Sample Ecore Model Editor we get an ArrayStoreException.
The Editor is entitled to object, but might do so more helpfully.
So, Restriction 1:
Any model referenced by an EEE model must be an EEE model. Seemingly obvious
but it means that Ecore and EMOF files cannot co-exist, a user must choose
one notation and ensure that all models comply with is notation.
N.B. EEE is not restricted to Ecore and EMOF; any notation for which there is
an EMF serialiser/deserialiser will do. EEE can define itself since
references to itself refer to itself by file name rather than URI.
Corrolary 1:
It will not be possible to use QVT models directly, it will be necessary to
create an EcoreQVT in which all referredProperty, referencedClass, usedPackage etc
refer to their Ecore counterparts.
My original problem was therefore that I had acquired QVT models in Ecore and
a QVT transformation on a QVT model violates Restriction 1 when the QVT model
is registered in Ecore format.
I therefore converted all the QVT files to its own EMOF variant, and after working
around <https://bugs.eclipse.org/bugs/show_bug.cgi?id=146305>, I am still unable to
use the Sample Ecore Model Editor because Restriction 1 is still violated; the
installed models are standard EMOF not QVT variant EMOF.
Fortunately Eclipse does not provide a registered package for
http://schema.omg.org/spec/mof/2.0/emof.xmi
so I could register the QVT variant EMOF as the standard.
Restriction 1 is now satisfied, albeit by subterfuge. The Sample Ecore
Model Editor still crashes, when attempting to view the modelParameters.
The root element of qvttemplate.emof, now
<emof:Package xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:emof="http://schema.omg.org/spec/mof/2.0/emof.xmi" xmi:id="qvttemplate"
name="qvttemplate" uri="http://www.eclipse.org/gmt/umlx/qvttemplate">
after access from the registry has been converted into a
org.eclipse.gmt.umlx.qvt.qvttemplate.impl.QvttemplatePackage Impl
which does not satisfy the list requirement for a
org.eclipse.gmt.umlx.qvt.emof.Package, even though the registered model
is/was an emof:Package.
Restriction 2:
It is not possible to register an EMOF model and access it as other than an Ecore model.
This is the incorrect usage access that prevents EMF as it stands being used
for EMOF meta-modelling.
Regards
Ed Willink
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #377206 is a reply to message #377204] |
Fri, 09 June 2006 21:59 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
I think this conversation will not get us very far because I get the
distinct feeling that the only way to satisfy your strict view of the
requirements is to delete Ecore and replace it with EMOF. But that's
something which simply isn't going to happen given that no EMOF exists
today and given that there's no well specified description of what that
would even look like. Not to mention the tens of millions of lines of
code and hundreds of thousands of clients are relying on what's
available today. Specific comments below.
Ed Willink wrote:
> Hi Ed
>
> > Ed Merks wrote
>> it seems to me that the generated ecore:EPackage should not have an
>> nsURI that collides with the logical URI of an emof:Package instance
>> since it results in an ambiguity as to whether the URI should refer to
>> an Ecore model or an EMOF model...
>
> This is a different way of making precisely my point. There must not be
> an ambiguity.
So why take the approach of introducing one?
> In fact, see later, it is not possible to register an EMOF
> model and for it to remain an EMOF model.
Of course you can only register an EPackage in the
EPackage.Registry.INSTANCE.
>
>> Even in the case of such ambiguity, you could specialize a
>> ResourceSetImpl's
>
> No I can't.
Why?
> I am trying to constrain this discussion to the more abstract
> perspective of consistent use of models within the Eclipse/EMF
> context. I am
> discussing properties that the standard (Java) code should exhibit not
> ones
> that my specialised application might introduce as a workaround.
Why do you insist that the whole environment must conform to your view
of consistency rather than working with what's possible to create an
environment that works exactly how you want it to work? It certainly
seems possible to me to build what you want if you take a different
approach...
>
> The problem showed up in the Sample Ecore Model Editor, which despite
> its title
> I (?mis-)interpret as Generic Model content viewer/editor.
>
> Some models are Ecore (i.e EPackage, EClass etc) - Ecore, OCL, UML2
>
> but the international standards are EMOF, OCL, UML2, QVT, .... and we
> must
> expect that further standards will be EMOF-based rather than Ecore-based.
We are able to consume .emof files, so the standards being in EMOF is
not an issue that prevents successful use of EMF to realize those models
in Java.
>
> EMF currently resolves the ambiguity by requiring that standards are
> re-engineered
> to use EClass rather than Class.
No. It simply interprets the the standard as Ecore on the fly with
absolutely no re-engineering is required.
> This is very undesirable. It would be better
> if EMOF and Ecore could co-exist seamlessly, with Ecore providing an
> effective
> implementation for an EMOF specification.
I could imagine an adapter based approach as was done to implement SDO
1.0, or an extension approach just as being done to implement SDO 2.at
Apache. But there's not a compelling use case since there is no
existing EMOF Java realization nor is one speced out.
>
> EMF has resolved two EMOF/Ecore incompatibilities by providing the
> ability to
> read/write EMOF or Ecore at will.
I wouldn't call this resolving an incompatibility any more than
importing schemas is resolving an incompatibility.
>
> I have unfortunately uncovered a third incompatibility with regard to
> the use
> of a model and consequently to use EMOF or Ecore at will.
>
> An XMI serialisation of a model defines its model elements using
> xsi:type and
> XML namespaces.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <qvtrelation:RelationalTransformation
> xmlns:qvtrelation="http:///qvtrelation.ecore"
> ...
> <modelParameter usedPackage="http:///qvttemplate.ecore#/" ...
>
> This is:
>
> XMIelement[tag='anon' type=qvtrelation:RelationalTransformation]
> XMIelement[tag=modelParameter type=qvtbase:TypedModel]
> XMIreference[tag=usedPackage type=emof:Package
> value="http:///qvttemplate.ecore#/"]
>
> (the first type is explicit, the latter two are implicit from the
> schema).
>
> I understand the XMIreference to mean at least 'resolve the value from
> the root element
> of the URI "http:///qvttemplate.ecore" and expect its type to be
> emof:Package'.
Not to belabor the point, but it's your choice to use a conflicting URI
and your unwillingness to specialize an environment to meet your needs
that results in this impasse.
>
> Confusingly for the purposes of this discussion, the ".ecore" in the
> URI indicates
> the technology that the author of the qvttemplate model used, so the
> URI appears
> to indicate Ecore. It doesn't it is just a longer name.
Go figure that folks wanting to implement something without several
person decades of initial investment would use Ecore! ;-)
>
> In order for EMF to resolve a URI, a Java class must be registered.
No. EMF is perfectly capable of resolve a URI that refers to something
other than a generated package.
> The resolution
> yields an EPackage for the root of qvttemplate.ecore which is in fact
>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
> name="qvttemplate"
> nsURI="http:///qvttemplate.ecore" nsPrefix="qvttemplate">
>
> this EPackage describes an ecore:EPackage named qvttemplate, not an
> emof:Package
> so the expectation that the URI root element is an emof:Package is not
> satisfied,
> and in the case of the Sample Ecore Model Editor we get an
> ArrayStoreException.
> The Editor is entitled to object, but might do so more helpfully.
>
> So, Restriction 1:
>
> Any model referenced by an EEE model must be an EEE model. Seemingly
> obvious
> but it means that Ecore and EMOF files cannot co-exist, a user must
> choose
> one notation and ensure that all models comply with is notation.
This is just a matter of creating an environment that has the
interpretation you desire. You could well set up an environment where a
..emof file is actually read in as an instance of an actual EMOF model
rather than as Ecore.
>
> N.B. EEE is not restricted to Ecore and EMOF; any notation for which
> there is
> an EMF serialiser/deserialiser will do. EEE can define itself since
> references to itself refer to itself by file name rather than URI.
Yes. We've clearly been able to support all other models without this
type of concern arising. This is why I'm not buying into the "it can't
be done argument"...
>
> Corrolary 1:
>
> It will not be possible to use QVT models directly, it will be
> necessary to
> create an EcoreQVT in which all referredProperty, referencedClass,
> usedPackage etc
> refer to their Ecore counterparts.
It should be possible to have an actual model for EMOF, create actual
instances of EMOF, and to refer to such instances. But that's a
specialized environment that Ecore doesn't provide out of the box for
you. (But I suspect that an EcoreQVT would be far more useful.)
>
> My original problem was therefore that I had acquired QVT models in
> Ecore and
> a QVT transformation on a QVT model violates Restriction 1 when the
> QVT model
> is registered in Ecore format.
Right. So you need to specialize your environment to meet your
specialized needs.
>
> I therefore converted all the QVT files to its own EMOF variant,
What does that mean, a variant? (Converting to Ecore is not acceptable?)
> and after working
> around <https://bugs.eclipse.org/bugs/show_bug.cgi?id=146305>, I am
> still unable to
> use the Sample Ecore Model Editor because Restriction 1 is still
> violated; the
> installed models are standard EMOF not QVT variant EMOF.
Not surprisingly, the Ecore editor will be focused on editing Ecore and
Ecore-based instances and cannot also be your EMOF environment at the
same time because of the apparent absolute need to use URIs with
conflicting interpretations.
>
> Fortunately Eclipse does not provide a registered package for
> http://schema.omg.org/spec/mof/2.0/emof.xmi
> so I could register the QVT variant EMOF as the standard.
Won't this also be an ecore:EPackage rather than an emof:Package? The
package registry of a resource set, by default delegates to the
EPackage.Registry.INSTANCE, but you can easily create a local package
registry that will not do that and hence won't see any globally
registered packages leaving you free to register or not register
whatever you like. You could define an EMOF Package registry...
>
> Restriction 1 is now satisfied, albeit by subterfuge.
Subterfuge doesn't sound so good...
> The Sample Ecore
> Model Editor still crashes, when attempting to view the modelParameters.
> The root element of qvttemplate.emof, now
>
> <emof:Package xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:emof="http://schema.omg.org/spec/mof/2.0/emof.xmi"
> xmi:id="qvttemplate"
> name="qvttemplate" uri="http://www.eclipse.org/gmt/umlx/qvttemplate">
>
> after access from the registry has been converted into a
> org.eclipse.gmt.umlx.qvt.qvttemplate.impl.QvttemplatePackage Impl
> which does not satisfy the list requirement for a
> org.eclipse.gmt.umlx.qvt.emof.Package, even though the registered model
> is/was an emof:Package.
It's clear by now that you should not expect Ecore to simply be EMOF.
>
> Restriction 2:
>
> It is not possible to register an EMOF model and access it as other
> than an Ecore model.
ResourceSet is very flexible and most certainly can be used to achieve
your goal, as I've described already.
>
> This is the incorrect usage access that prevents EMF as it stands
> being used
> for EMOF meta-modelling.
I think you are simply expecting Ecore to already be EMOF and that you
aren't willing to build your own layer of technology that will meet your
needs. You should consider taking a a different approach. Don't push
against the river, flow with it...
>
> Regards
>
> Ed Willink
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #377208 is a reply to message #377206] |
Sat, 10 June 2006 05:56 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
Ed Merks wrote:
> I think this conversation will not get us very far because I get the
> distinct feeling that the only way to satisfy your strict view of the
> requirements is to delete Ecore and replace it with EMOF. But that's
> something which simply isn't going to happen given that no EMOF exists
> today and given that there's no well specified description of what that
> would even look like. Not to mention the tens of millions of lines of
> code and hundreds of thousands of clients are relying on what's
> available today. Specific comments below.
You seem to have completely misunderstood my motivation.
Obviously Ecore cannot be obsoleted,
a) for very obvious financial/ergonomic reasons
and certainly not in favour of EMOF
b) because EMOF cannot be precisely realized in Java
In principle there is no reason why the (hidden) model implementation has to be
the same technology as the (overt) model specification. If that were not the
case we would have to use XMI for everything. No DOM, no Ecore, no MDR, no EMOF, no ...
As I pointed out, EMF provides Ecore/EMOF equivalence on input/output interfaces.
Unfortunately I've uncovered a context where Ecore implementation and EMOF specification
have been confused, and consequently I've become confused and no doubt confusing in
my exposition of the problem.
If the deficiency is not remedied there is going to be an implementation dilemma/delay
for every new EMOF-based specification, and as/if we move to a more meta-model dependent
environment this could get very embarrassing.
So let's try to agree on the problem so that we can find solutions that allow
the power of Ecore-based implementations to support the flexibility of EMOF-based
specifications and standards.
(After falling over Bug 146305, I think that a solution may be as simple as ensuring that
consistent implementation/specification. Modeled elements use the appropriate model
implementation i.e. Ecore; i.e. an inter-model reference to an emof:Package specification
gets an Ecore implementation of an emof:Package, just as an inter-model opposite reference
gets an Ecore implementation of an emof:Property rather than whoops an ecore:EReference.
.... Then we can discuss model registration.)
Regards
Ed Willink
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #377210 is a reply to message #377208] |
Sat, 10 June 2006 14:48 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Willink wrote:
> Hi Ed
>
> Ed Merks wrote:
>> I think this conversation will not get us very far because I get the
>> distinct feeling that the only way to satisfy your strict view of the
>> requirements is to delete Ecore and replace it with EMOF. But that's
>> something which simply isn't going to happen given that no EMOF
>> exists today and given that there's no well specified description of
>> what that would even look like. Not to mention the tens of millions
>> of lines of code and hundreds of thousands of clients are relying on
>> what's available today. Specific comments below.
>
> You seem to have completely misunderstood my motivation.
Sorry. Probably I did. Sometimes I get cranky at the end of a long
day. It's frustrating not to be able to make everyone happy, even
though it's clearly a futile thing to try to do. ;-)
>
> Obviously Ecore cannot be obsoleted,
> a) for very obvious financial/ergonomic reasons
> and certainly not in favour of EMOF
> b) because EMOF cannot be precisely realized in Java
>
> In principle there is no reason why the (hidden) model implementation
> has to be
> the same technology as the (overt) model specification. If that were
> not the
> case we would have to use XMI for everything. No DOM, no Ecore, no
> MDR, no EMOF, no ...
>
> As I pointed out, EMF provides Ecore/EMOF equivalence on input/output
> interfaces.
> Unfortunately I've uncovered a context where Ecore implementation and
> EMOF specification
> have been confused, and consequently I've become confused and no doubt
> confusing in
> my exposition of the problem.
>
> If the deficiency is not remedied there is going to be an
> implementation dilemma/delay
> for every new EMOF-based specification, and as/if we move to a more
> meta-model dependent
> environment this could get very embarrassing.
>
> So let's try to agree on the problem so that we can find solutions
> that allow
> the power of Ecore-based implementations to support the flexibility of
> EMOF-based
> specifications and standards.
Cool. I would certainly like to help eliminate any problems we can and
to provide the best possible support we can.
>
> (After falling over Bug 146305, I think that a solution may be as
> simple as ensuring that
> consistent implementation/specification. Modeled elements use the
> appropriate model
> implementation i.e. Ecore; i.e. an inter-model reference to an
> emof:Package specification
> gets an Ecore implementation of an emof:Package, just as an
> inter-model opposite reference
> gets an Ecore implementation of an emof:Property rather than whoops an
> ecore:EReference.
> ... Then we can discuss model registration.)
Yeah. I could imagine some type of automatic wrapping/adapting. I'll
be interested to follow up on any good ideas...
>
> Regards
>
> Ed Willink
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Is Ecore fit for EMOF meta-modeling? [message #573418 is a reply to message #377176] |
Tue, 06 June 2006 19:18 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Willink wrote:
> I have recently encountered some nasty problems when trying to use
> Ecore as
> the underlying technology for QVT and consequently EMOF-based modeling.
>
> The problem is that QVT is based on EMOF and so defined in EMOF and so
> at some meta-meta-... level the model must be EMOF.
What does that mean though? Ecore can be serialized as EMOF and can be
deserialized from EMOF.
>
> Ecore is effective as a generator of executable Java models, for which
> at some meta-meta-... level the model is Ecore.
That's one of the things it's for but given that it supports dynamic
model instances for which no code is ever generated, that's not the only
thing it's for.
>
> Now if QVT is modeled using EMF, it is possible to register QVT as an
> Ecore package and to have a consistent model that uses EMOF. However a
> QVT
> transformation applied to a QVT model must be able to access the QVT
> meta-model,
> and that meta-model is Ecore not EMOF, so unless EMF provides an
> ability to
> access (rather than just serialise) a registered Ecore model as EMOF,
> it is not possible
> to traverse the meta-levels of QVT without crossing from EMOF to Ecore
> and
> getting type violations.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239
Again, what does this mean? EMOF's Java realization is not well
specified so I would argue that Ecore's API is the EMOF's Java realization.
>
> We seem to have 2 choices, either every EMOF derived model must acquire a
> an E counterpart. We already have (E)OCL, but we will need EQVT etc,
> etc, etc.
What does EMOF have that isn't already in the Ecore API?
>
> Or we recognise that EMOF-based modeling should be EMOF-based.
And that would imply what additional things that aren't already there in
Ecore today?
>
> The latter means that resolution of the QVT URI must be able to
> resolve to
> qvt.emof.
>
> A closely related problem that I have observed with OMELET, Tefkat,
> ATL and
> MOFScript, is how to convert a meta-model-name into a
> model-model-content.
>
> The EMF Package registry provides a partial solution, using a URI as a
> meta-model-name, but it only works for meta-models
> that have been successfuly converted to Java code. This is not
> possible for
> unmodified EMOF models, since nsURI and instanceClassName nulls cause
> NPEs in
> genmodel, and anyway, why is it necessary to generate Java code when
> none is wanted?
This seems to be a misunderstanding. The packages registered in the
EPackage.Registry.INSTANCE need not correspond to generated packages
only. Also, the instanceClassName is an issue only for EDataTypes and
in that case the class is needed as much to support a dynamic instances
as it is to generate Java code.
>
> It seems that the EMF Package registry should have two forms of
> registration:
> URI => implementing Java class, genModel file name
> URI => emofModel file name
> so that the latter can be consistently used for EMOF-based
> meta-modelling, and the former
> for Java-based executables. The emofModel could be auto-generated by
> genModel for Java-based
> models.
Anyone needing to register models that aren't ever generated could add
such an extension point. We could add one to EMF in the next release if
this would be useful in general (though not generating a model
statically but still registering it statically seems kind of odd).
>
> We just need an ability to register emofModels in plugin.xml. To avoid
> the
> inconvenience of starting up nested Eclipse sessions, we need a
> registered package
> browser that supports maintenance and loading of perhaps a .metamodels
> file per
> project.
I could imagine the extension point being just like generated_packages,
but would specify the URI of the .ecore/.emof serialization rather than
the name of the implementing package class.
>
> Regards
>
> Ed Willink
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Is Ecore fit for EMOF meta-modeling? [message #573493 is a reply to message #377182] |
Thu, 08 June 2006 19:54 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000005080506010208010703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
I'm a bit confused. I particularly don't understand this part:
The problem is that the transformation model refers to the QVT model
by its URI, and EMF is currently only able to resolve this by
supplying the Java
support which is an Ecore(emof:Package).
I understand why a logical URI might be used to refer to a model and for
that EMF's resource set's URI converter provides for URI mappings to
redirect a logical URI to a physical URI. This could be used to map an
emof:Package's URI to a resource containing an actual emof:Package
instance. But in 145239
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239> that's not what
you seem to be doing. You seem to using the nsURI of a generated
ecore:EPackage to refer to what you expect will be an emof:Package. So
it seems to me that the generated ecore:EPackage should not have an
nsURI that collides with the logical URI of an emof:Package instance
since it results in an ambiguity as to whether the URI should refer to
an Ecore model or an EMOF model...
Even in the case of such ambiguity, you could specialize a
ResourceSetImpl's
protected Resource delegatedGetResource(URI uri, boolean loadOnDemand)
{
EPackage ePackage =
getPackageRegistry().getEPackage(uri.toString());
return ePackage == null ? null : ePackage.eResource();
}
to redirect logical emof:Package URIs to an EMOF package registry
instead of the default ecore:EPackage registry.
Ed Willink wrote:
> Hi Ed
>
> To avoid unnecessary confusions, I'll refrain from commenting about
> solutions until we're agreed on the problem.
>
> And to avoid a further confusion, let me make it clear that I think
> EMF offers very powerful facilities with a helpful API for managing
> models
> within a Java context.
>
> My comments are entirely directed to problems that arise once meta-models
> are used in a more general sense. Hence my posting to this rather than
> the
> EMF newsgroup.
>
> Let me introduce a little notation.
>
> EMOF(x) represents the modeled type of x in EMOF.
> Ecore(x) represents the modeled type of x in Ecore.
>
> Thus EMOF(emof:Package) is emof:Package.
> and Ecore(emof:Package) is ecore:EPackage.
>
> The QVT packages extend the EMOF packages and includes references to
> its own types.
>
> Thus a
>
> qvtbase:TypedModel.usedPackage is an ecore:Package.
>
> so a model conforming to the QVT meta-model may have a
> qvtbase:TypedModel element.
> If this model is a transformation model that transforming QVT models
> we may have
> a qvtbase:TypedModel element that refers to the emof:Package
> describing the emof:Package.
>
> This can work fine so long as EMOF is modelled by EMOF.
>
> However it doesn't work when EMOF is modelled by Ecore.
>
> The problem is that the transformation model refers to the QVT model
> by its
> URI, and EMF is currently only able to resolve this by supplying the Java
> support which is an Ecore(emof:Package). Consequently when the Sample
> Ecore
> Editor attempts to peruse the model it fails because it finds it has an
> EPackage (Ecore(emof:Package)) when the meta-model requires an
> ecore:Package.
>
> EMF has useful for support for EMOF at its external interfaces, but
> has no
> support for EMOF internally. The meta-modelling/transformation
> perspective in
> which the types of models are traversed more deeply exposes this
> limitation.
>
> A modeling technique XXX for xxx must ensure that
>
> XXX(xxx:Package) is (not incompatible with) xxx:Package
>
> Regards
>
> Ed Willink
>
--------------000005080506010208010703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
I'm a bit confused. I particularly don't understand this part:<br>
<blockquote>The problem is that the transformation model refers to the
QVT model by its
URI, and EMF is currently only able to resolve this by supplying the
Java
<br>
support which is an Ecore(emof:Package).<br>
</blockquote>
I understand why a logical URI might be used to refer to a model and
for that EMF's resource set's URI converter provides for URI mappings
to redirect a logical URI to a physical URI. This could be used to map
an emof:Package's URI to a resource containing an actual emof:Package
instance. But in <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239">145239</a>
that's not what you seem to be doing. You seem to using the nsURI of a
generated ecore:EPackage to refer to what you expect will be an
emof:Package. So it seems to me that the generated ecore:EPackage
should not have an nsURI that collides with the logical URI of an
emof:Package instance since it results in an ambiguity as to whether
the URI should refer to an Ecore model or an EMOF model...<br>
<br>
Even in the case of such ambiguity, you could specialize a
ResourceSetImpl's <br>
<blockquote> protected Resource delegatedGetResource(URI uri, boolean
loadOnDemand)<br>
{<br>
EPackage ePackage =
getPackageRegistry().getEPackage(uri.toString());<br>
return ePackage == null ? null : ePackage.eResource();<br>
}<br>
</blockquote>
to redirect logical emof:Package URIs to an EMOF package registry
instead of the default ecore:EPackage registry.<br>
<br>
<br>
Ed Willink wrote:
<blockquote cite="mide69q1n$lkk$1@utils.eclipse.org" type="cite">Hi Ed
<br>
<br>
To avoid unnecessary confusions, I'll refrain from commenting about
<br>
solutions until we're agreed on the problem.
<br>
<br>
And to avoid a further confusion, let me make it clear that I think
<br>
EMF offers very powerful facilities with a helpful API for managing
models
<br>
within a Java context.
<br>
<br>
My comments are entirely directed to problems that arise once
meta-models
<br>
are used in a more general sense. Hence my posting to this rather than
the
<br>
EMF newsgroup.
<br>
<br>
Let me introduce a little notation.
<br>
<br>
EMOF(x) represents the modeled type of x in EMOF.
<br>
Ecore(x) represents the modeled type of x in Ecore.
<br>
<br>
Thus EMOF(emof:Package) is emof:Package.
<br>
and Ecore(emof:Package) is ecore:EPackage.
<br>
<br>
The QVT packages extend the EMOF packages and includes references to
its own types.
<br>
<br>
Thus a
<br>
<br>
qvtbase:TypedModel.u sedPackage is an ecore:Package.
<br>
<br>
so a model conforming to the QVT meta-model may have a
qvtbase:TypedModel element.
<br>
If this model is a transformation model that transforming QVT models we
may have
<br>
a qvtbase:TypedModel element that refers to the emof:Package describing
the emof:Package.
<br>
<br>
This can work fine so long as EMOF is modelled by EMOF.
<br>
<br>
However it doesn't work when EMOF is modelled by Ecore.
<br>
<br>
The problem is that the transformation model refers to the QVT model by
its
<br>
URI, and EMF is currently only able to resolve this by supplying the
Java
<br>
support which is an Ecore(emof:Package). Consequently when the Sample
Ecore
<br>
Editor attempts to peruse the model it fails because it finds it has an
<br>
EPackage (Ecore(emof:Package)) when the meta-model requires an
ecore:Package.
<br>
<br>
EMF has useful for support for EMOF at its external interfaces, but has
no
<br>
support for EMOF internally. The meta-modelling/transformation
perspective in
<br>
which the types of models are traversed more deeply exposes this
limitation.
<br>
<br>
A modeling technique XXX for xxx must ensure that
<br>
<br>
XXX(xxx:Package) is (not incompatible with) xxx:Package
<br>
<br>
Regards
<br>
<br>
Ed Willink
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------000005080506010208010703--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #577948 is a reply to message #377184] |
Fri, 09 June 2006 19:31 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
> Ed Merks wrote
> it seems to me that the generated ecore:EPackage should not have an
> nsURI that collides with the logical URI of an emof:Package instance
> since it results in an ambiguity as to whether the URI should refer to
> an Ecore model or an EMOF model...
This is a different way of making precisely my point. There must not be
an ambiguity. In fact, see later, it is not possible to register an EMOF
model and for it to remain an EMOF model.
> Even in the case of such ambiguity, you could specialize a
> ResourceSetImpl's
No I can't. I am trying to constrain this discussion to the more abstract
perspective of consistent use of models within the Eclipse/EMF context. I am
discussing properties that the standard (Java) code should exhibit not ones
that my specialised application might introduce as a workaround.
The problem showed up in the Sample Ecore Model Editor, which despite its title
I (?mis-)interpret as Generic Model content viewer/editor.
Some models are Ecore (i.e EPackage, EClass etc) - Ecore, OCL, UML2
but the international standards are EMOF, OCL, UML2, QVT, .... and we must
expect that further standards will be EMOF-based rather than Ecore-based.
EMF currently resolves the ambiguity by requiring that standards are re-engineered
to use EClass rather than Class. This is very undesirable. It would be better
if EMOF and Ecore could co-exist seamlessly, with Ecore providing an effective
implementation for an EMOF specification.
EMF has resolved two EMOF/Ecore incompatibilities by providing the ability to
read/write EMOF or Ecore at will.
I have unfortunately uncovered a third incompatibility with regard to the use
of a model and consequently to use EMOF or Ecore at will.
An XMI serialisation of a model defines its model elements using xsi:type and
XML namespaces.
<?xml version="1.0" encoding="UTF-8"?>
<qvtrelation:RelationalTransformation xmlns:qvtrelation="http:///qvtrelation.ecore"
...
<modelParameter usedPackage="http:///qvttemplate.ecore#/" ...
This is:
XMIelement[tag='anon' type=qvtrelation:RelationalTransformation]
XMIelement[tag=modelParameter type=qvtbase:TypedModel]
XMIreference[tag=usedPackage type=emof:Package value="http:///qvttemplate.ecore#/"]
(the first type is explicit, the latter two are implicit from the schema).
I understand the XMIreference to mean at least 'resolve the value from the root element
of the URI "http:///qvttemplate.ecore" and expect its type to be emof:Package'.
Confusingly for the purposes of this discussion, the ".ecore" in the URI indicates
the technology that the author of the qvttemplate model used, so the URI appears
to indicate Ecore. It doesn't it is just a longer name.
In order for EMF to resolve a URI, a Java class must be registered. The resolution
yields an EPackage for the root of qvttemplate.ecore which is in fact
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="qvttemplate"
nsURI="http:///qvttemplate.ecore" nsPrefix="qvttemplate">
this EPackage describes an ecore:EPackage named qvttemplate, not an emof:Package
so the expectation that the URI root element is an emof:Package is not satisfied,
and in the case of the Sample Ecore Model Editor we get an ArrayStoreException.
The Editor is entitled to object, but might do so more helpfully.
So, Restriction 1:
Any model referenced by an EEE model must be an EEE model. Seemingly obvious
but it means that Ecore and EMOF files cannot co-exist, a user must choose
one notation and ensure that all models comply with is notation.
N.B. EEE is not restricted to Ecore and EMOF; any notation for which there is
an EMF serialiser/deserialiser will do. EEE can define itself since
references to itself refer to itself by file name rather than URI.
Corrolary 1:
It will not be possible to use QVT models directly, it will be necessary to
create an EcoreQVT in which all referredProperty, referencedClass, usedPackage etc
refer to their Ecore counterparts.
My original problem was therefore that I had acquired QVT models in Ecore and
a QVT transformation on a QVT model violates Restriction 1 when the QVT model
is registered in Ecore format.
I therefore converted all the QVT files to its own EMOF variant, and after working
around <https://bugs.eclipse.org/bugs/show_bug.cgi?id=146305>, I am still unable to
use the Sample Ecore Model Editor because Restriction 1 is still violated; the
installed models are standard EMOF not QVT variant EMOF.
Fortunately Eclipse does not provide a registered package for
http://schema.omg.org/spec/mof/2.0/emof.xmi
so I could register the QVT variant EMOF as the standard.
Restriction 1 is now satisfied, albeit by subterfuge. The Sample Ecore
Model Editor still crashes, when attempting to view the modelParameters.
The root element of qvttemplate.emof, now
<emof:Package xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:emof="http://schema.omg.org/spec/mof/2.0/emof.xmi" xmi:id="qvttemplate"
name="qvttemplate" uri="http://www.eclipse.org/gmt/umlx/qvttemplate">
after access from the registry has been converted into a
org.eclipse.gmt.umlx.qvt.qvttemplate.impl.QvttemplatePackage Impl
which does not satisfy the list requirement for a
org.eclipse.gmt.umlx.qvt.emof.Package, even though the registered model
is/was an emof:Package.
Restriction 2:
It is not possible to register an EMOF model and access it as other than an Ecore model.
This is the incorrect usage access that prevents EMF as it stands being used
for EMOF meta-modelling.
Regards
Ed Willink
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #577994 is a reply to message #377204] |
Fri, 09 June 2006 21:59 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
I think this conversation will not get us very far because I get the
distinct feeling that the only way to satisfy your strict view of the
requirements is to delete Ecore and replace it with EMOF. But that's
something which simply isn't going to happen given that no EMOF exists
today and given that there's no well specified description of what that
would even look like. Not to mention the tens of millions of lines of
code and hundreds of thousands of clients are relying on what's
available today. Specific comments below.
Ed Willink wrote:
> Hi Ed
>
> > Ed Merks wrote
>> it seems to me that the generated ecore:EPackage should not have an
>> nsURI that collides with the logical URI of an emof:Package instance
>> since it results in an ambiguity as to whether the URI should refer to
>> an Ecore model or an EMOF model...
>
> This is a different way of making precisely my point. There must not be
> an ambiguity.
So why take the approach of introducing one?
> In fact, see later, it is not possible to register an EMOF
> model and for it to remain an EMOF model.
Of course you can only register an EPackage in the
EPackage.Registry.INSTANCE.
>
>> Even in the case of such ambiguity, you could specialize a
>> ResourceSetImpl's
>
> No I can't.
Why?
> I am trying to constrain this discussion to the more abstract
> perspective of consistent use of models within the Eclipse/EMF
> context. I am
> discussing properties that the standard (Java) code should exhibit not
> ones
> that my specialised application might introduce as a workaround.
Why do you insist that the whole environment must conform to your view
of consistency rather than working with what's possible to create an
environment that works exactly how you want it to work? It certainly
seems possible to me to build what you want if you take a different
approach...
>
> The problem showed up in the Sample Ecore Model Editor, which despite
> its title
> I (?mis-)interpret as Generic Model content viewer/editor.
>
> Some models are Ecore (i.e EPackage, EClass etc) - Ecore, OCL, UML2
>
> but the international standards are EMOF, OCL, UML2, QVT, .... and we
> must
> expect that further standards will be EMOF-based rather than Ecore-based.
We are able to consume .emof files, so the standards being in EMOF is
not an issue that prevents successful use of EMF to realize those models
in Java.
>
> EMF currently resolves the ambiguity by requiring that standards are
> re-engineered
> to use EClass rather than Class.
No. It simply interprets the the standard as Ecore on the fly with
absolutely no re-engineering is required.
> This is very undesirable. It would be better
> if EMOF and Ecore could co-exist seamlessly, with Ecore providing an
> effective
> implementation for an EMOF specification.
I could imagine an adapter based approach as was done to implement SDO
1.0, or an extension approach just as being done to implement SDO 2.at
Apache. But there's not a compelling use case since there is no
existing EMOF Java realization nor is one speced out.
>
> EMF has resolved two EMOF/Ecore incompatibilities by providing the
> ability to
> read/write EMOF or Ecore at will.
I wouldn't call this resolving an incompatibility any more than
importing schemas is resolving an incompatibility.
>
> I have unfortunately uncovered a third incompatibility with regard to
> the use
> of a model and consequently to use EMOF or Ecore at will.
>
> An XMI serialisation of a model defines its model elements using
> xsi:type and
> XML namespaces.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <qvtrelation:RelationalTransformation
> xmlns:qvtrelation="http:///qvtrelation.ecore"
> ...
> <modelParameter usedPackage="http:///qvttemplate.ecore#/" ...
>
> This is:
>
> XMIelement[tag='anon' type=qvtrelation:RelationalTransformation]
> XMIelement[tag=modelParameter type=qvtbase:TypedModel]
> XMIreference[tag=usedPackage type=emof:Package
> value="http:///qvttemplate.ecore#/"]
>
> (the first type is explicit, the latter two are implicit from the
> schema).
>
> I understand the XMIreference to mean at least 'resolve the value from
> the root element
> of the URI "http:///qvttemplate.ecore" and expect its type to be
> emof:Package'.
Not to belabor the point, but it's your choice to use a conflicting URI
and your unwillingness to specialize an environment to meet your needs
that results in this impasse.
>
> Confusingly for the purposes of this discussion, the ".ecore" in the
> URI indicates
> the technology that the author of the qvttemplate model used, so the
> URI appears
> to indicate Ecore. It doesn't it is just a longer name.
Go figure that folks wanting to implement something without several
person decades of initial investment would use Ecore! ;-)
>
> In order for EMF to resolve a URI, a Java class must be registered.
No. EMF is perfectly capable of resolve a URI that refers to something
other than a generated package.
> The resolution
> yields an EPackage for the root of qvttemplate.ecore which is in fact
>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
> name="qvttemplate"
> nsURI="http:///qvttemplate.ecore" nsPrefix="qvttemplate">
>
> this EPackage describes an ecore:EPackage named qvttemplate, not an
> emof:Package
> so the expectation that the URI root element is an emof:Package is not
> satisfied,
> and in the case of the Sample Ecore Model Editor we get an
> ArrayStoreException.
> The Editor is entitled to object, but might do so more helpfully.
>
> So, Restriction 1:
>
> Any model referenced by an EEE model must be an EEE model. Seemingly
> obvious
> but it means that Ecore and EMOF files cannot co-exist, a user must
> choose
> one notation and ensure that all models comply with is notation.
This is just a matter of creating an environment that has the
interpretation you desire. You could well set up an environment where a
..emof file is actually read in as an instance of an actual EMOF model
rather than as Ecore.
>
> N.B. EEE is not restricted to Ecore and EMOF; any notation for which
> there is
> an EMF serialiser/deserialiser will do. EEE can define itself since
> references to itself refer to itself by file name rather than URI.
Yes. We've clearly been able to support all other models without this
type of concern arising. This is why I'm not buying into the "it can't
be done argument"...
>
> Corrolary 1:
>
> It will not be possible to use QVT models directly, it will be
> necessary to
> create an EcoreQVT in which all referredProperty, referencedClass,
> usedPackage etc
> refer to their Ecore counterparts.
It should be possible to have an actual model for EMOF, create actual
instances of EMOF, and to refer to such instances. But that's a
specialized environment that Ecore doesn't provide out of the box for
you. (But I suspect that an EcoreQVT would be far more useful.)
>
> My original problem was therefore that I had acquired QVT models in
> Ecore and
> a QVT transformation on a QVT model violates Restriction 1 when the
> QVT model
> is registered in Ecore format.
Right. So you need to specialize your environment to meet your
specialized needs.
>
> I therefore converted all the QVT files to its own EMOF variant,
What does that mean, a variant? (Converting to Ecore is not acceptable?)
> and after working
> around <https://bugs.eclipse.org/bugs/show_bug.cgi?id=146305>, I am
> still unable to
> use the Sample Ecore Model Editor because Restriction 1 is still
> violated; the
> installed models are standard EMOF not QVT variant EMOF.
Not surprisingly, the Ecore editor will be focused on editing Ecore and
Ecore-based instances and cannot also be your EMOF environment at the
same time because of the apparent absolute need to use URIs with
conflicting interpretations.
>
> Fortunately Eclipse does not provide a registered package for
> http://schema.omg.org/spec/mof/2.0/emof.xmi
> so I could register the QVT variant EMOF as the standard.
Won't this also be an ecore:EPackage rather than an emof:Package? The
package registry of a resource set, by default delegates to the
EPackage.Registry.INSTANCE, but you can easily create a local package
registry that will not do that and hence won't see any globally
registered packages leaving you free to register or not register
whatever you like. You could define an EMOF Package registry...
>
> Restriction 1 is now satisfied, albeit by subterfuge.
Subterfuge doesn't sound so good...
> The Sample Ecore
> Model Editor still crashes, when attempting to view the modelParameters.
> The root element of qvttemplate.emof, now
>
> <emof:Package xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:emof="http://schema.omg.org/spec/mof/2.0/emof.xmi"
> xmi:id="qvttemplate"
> name="qvttemplate" uri="http://www.eclipse.org/gmt/umlx/qvttemplate">
>
> after access from the registry has been converted into a
> org.eclipse.gmt.umlx.qvt.qvttemplate.impl.QvttemplatePackage Impl
> which does not satisfy the list requirement for a
> org.eclipse.gmt.umlx.qvt.emof.Package, even though the registered model
> is/was an emof:Package.
It's clear by now that you should not expect Ecore to simply be EMOF.
>
> Restriction 2:
>
> It is not possible to register an EMOF model and access it as other
> than an Ecore model.
ResourceSet is very flexible and most certainly can be used to achieve
your goal, as I've described already.
>
> This is the incorrect usage access that prevents EMF as it stands
> being used
> for EMOF meta-modelling.
I think you are simply expecting Ecore to already be EMOF and that you
aren't willing to build your own layer of technology that will meet your
needs. You should consider taking a a different approach. Don't push
against the river, flow with it...
>
> Regards
>
> Ed Willink
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #578013 is a reply to message #377206] |
Sat, 10 June 2006 05:56 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
Ed Merks wrote:
> I think this conversation will not get us very far because I get the
> distinct feeling that the only way to satisfy your strict view of the
> requirements is to delete Ecore and replace it with EMOF. But that's
> something which simply isn't going to happen given that no EMOF exists
> today and given that there's no well specified description of what that
> would even look like. Not to mention the tens of millions of lines of
> code and hundreds of thousands of clients are relying on what's
> available today. Specific comments below.
You seem to have completely misunderstood my motivation.
Obviously Ecore cannot be obsoleted,
a) for very obvious financial/ergonomic reasons
and certainly not in favour of EMOF
b) because EMOF cannot be precisely realized in Java
In principle there is no reason why the (hidden) model implementation has to be
the same technology as the (overt) model specification. If that were not the
case we would have to use XMI for everything. No DOM, no Ecore, no MDR, no EMOF, no ...
As I pointed out, EMF provides Ecore/EMOF equivalence on input/output interfaces.
Unfortunately I've uncovered a context where Ecore implementation and EMOF specification
have been confused, and consequently I've become confused and no doubt confusing in
my exposition of the problem.
If the deficiency is not remedied there is going to be an implementation dilemma/delay
for every new EMOF-based specification, and as/if we move to a more meta-model dependent
environment this could get very embarrassing.
So let's try to agree on the problem so that we can find solutions that allow
the power of Ecore-based implementations to support the flexibility of EMOF-based
specifications and standards.
(After falling over Bug 146305, I think that a solution may be as simple as ensuring that
consistent implementation/specification. Modeled elements use the appropriate model
implementation i.e. Ecore; i.e. an inter-model reference to an emof:Package specification
gets an Ecore implementation of an emof:Package, just as an inter-model opposite reference
gets an Ecore implementation of an emof:Property rather than whoops an ecore:EReference.
.... Then we can discuss model registration.)
Regards
Ed Willink
|
|
|
| Re: Is Ecore fit for EMOF meta-modeling? [message #578044 is a reply to message #377208] |
Sat, 10 June 2006 14:48 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Willink wrote:
> Hi Ed
>
> Ed Merks wrote:
>> I think this conversation will not get us very far because I get the
>> distinct feeling that the only way to satisfy your strict view of the
>> requirements is to delete Ecore and replace it with EMOF. But that's
>> something which simply isn't going to happen given that no EMOF
>> exists today and given that there's no well specified description of
>> what that would even look like. Not to mention the tens of millions
>> of lines of code and hundreds of thousands of clients are relying on
>> what's available today. Specific comments below.
>
> You seem to have completely misunderstood my motivation.
Sorry. Probably I did. Sometimes I get cranky at the end of a long
day. It's frustrating not to be able to make everyone happy, even
though it's clearly a futile thing to try to do. ;-)
>
> Obviously Ecore cannot be obsoleted,
> a) for very obvious financial/ergonomic reasons
> and certainly not in favour of EMOF
> b) because EMOF cannot be precisely realized in Java
>
> In principle there is no reason why the (hidden) model implementation
> has to be
> the same technology as the (overt) model specification. If that were
> not the
> case we would have to use XMI for everything. No DOM, no Ecore, no
> MDR, no EMOF, no ...
>
> As I pointed out, EMF provides Ecore/EMOF equivalence on input/output
> interfaces.
> Unfortunately I've uncovered a context where Ecore implementation and
> EMOF specification
> have been confused, and consequently I've become confused and no doubt
> confusing in
> my exposition of the problem.
>
> If the deficiency is not remedied there is going to be an
> implementation dilemma/delay
> for every new EMOF-based specification, and as/if we move to a more
> meta-model dependent
> environment this could get very embarrassing.
>
> So let's try to agree on the problem so that we can find solutions
> that allow
> the power of Ecore-based implementations to support the flexibility of
> EMOF-based
> specifications and standards.
Cool. I would certainly like to help eliminate any problems we can and
to provide the best possible support we can.
>
> (After falling over Bug 146305, I think that a solution may be as
> simple as ensuring that
> consistent implementation/specification. Modeled elements use the
> appropriate model
> implementation i.e. Ecore; i.e. an inter-model reference to an
> emof:Package specification
> gets an Ecore implementation of an emof:Package, just as an
> inter-model opposite reference
> gets an Ecore implementation of an emof:Property rather than whoops an
> ecore:EReference.
> ... Then we can discuss model registration.)
Yeah. I could imagine some type of automatic wrapping/adapting. I'll
be interested to follow up on any good ideas...
>
> Regards
>
> Ed Willink
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 12:41:06 GMT 2024
Powered by FUDForum. Page generated in 0.04824 seconds |
] 
Search
Help
Register
Login
Home
