[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emft-dev] [EMFatic] Alignment with OCLinEcore
|
Hi Sven
On Apr 7, 2010, at 7:47 AM, Ed Willink wrote:
Xtext does not allow a non-trivial rule to return a String!
What does that mean? Are you referring to an existing bug report?
Not an existing report that I know of. Maybe I'll raise one, maybe I'll
discover that I was being foolish.
What persistent representation do you plan for Emfatic? Xtext does a
very good job of hiding the XML representation, but the use of
*.ecore is very entrenched, so I'm not sure that all *.ecore will
migrate to *.emfatic.
Text. As soon as people want to leverage emfatic, I expect them to be
able to switch to the concrete syntax in order to leverage not only
the text editor, but also all other advantages (search and replace,
diff, merge, etc.).
There will probably be actions to convert from *.ecore to *.emfatic
(or whatever that file extension will be), but I don't see why a
conversion into the other direction could be useful.
That's certainly nice and simple, but does it always work?
Suppose I have a metamodel Mine.ecore and I have many existing models
that exploit it, so there are logical and/or physical proxies involving
Mine.ecore.
If I migrate to Mine.emfatic, aren't the old proxies broken?
If Mine.emfatic is installed with a plugin registration, I guess the EMF
URI Resolver can autoload it.
However if Mine.ecore is a run-time model, the URI will go unresolved;
unless some run-time URI Resolver such as the OCL Model Registry
resolves it.
[Not a problem for Ecore/Emfatic, but for meta-models using UUIDs is
there a way of stabilising references once the meta-model is promoted to
textual form?]
I'm finding it not too hard to provide a variant DocumentProvider so
that *.ecore is the persistent representation for OCL in Ecore. On
load, the Document InputStream starts as the Ecore XML that is loaded
as an Ecore AST and is then transformed to a similar CST which is
serialised to provide the OCLinEcore InputSteam for conventional
editing. On save, the CST is transformed back to the Ecore AST which
is saved.
Yes, it's possible but complicated, isn't it?
Why should people want to stick with XMI?
1) It's at least comforting to be able to have the old-style file and to
examine it using very old-style tools.
It is amazing how useful a naked text editor is sometimes. I have had to
mend my OCLinEcoreCST.ecore a couple of times to correct Ecore
references to point at the logical rather than physical URI. Xtext gets
confused by a mixture. Maybe this couldn't have gone wrong in Emfatic.
2) Reading an Xtext file is faster than reading an XMI file, but by the
time loading has transformed the read into EObjects, XMI is surely
noticeably faster.
How would you like to progress the Emfatic-OCL dependency?
As I said, I have no plans to implement an Emfatic editor based on OCL.
If you want to do it, I think Emfatic needs to depend on OCL and not
vice versa. Is that the question?
That is the question, but it's not the answer I expected, did you mis-type?
Your two statements seem contradictory, unless OCLinEcore and Emfatic
are merged, presumably within Emfatic, in which case there is an Emfatic
editor using OCL.
Shall I just produce my OCLinEmfatic/OCLinEcore editor as an example for
Helios, then you can review it and decide how best to provide shared
functionality in Iona?
Regards
Ed Willink
