Skip to main content

[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?


        Ed Willink

Back to the top