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 Ed,

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?

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.

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?

The 'similar' CST is needed to make the serialiser work on Ecore. It solves simple problems such as:
'readonly' is inverted from EStructuralFeature.changeable
'ordered' is default not-ordered in CS but default ordered in Ecore
multiplicity has '*' representation for upperBound -1, and also '?' short forms
embedded OCL annotations need first class representation
other annotations need a representation

[The serialiser seems quite slow. A direct Java implementation seems attractive if the XML input is common and would not have such struct exact-serialisability constraints.]

Since both *.emfatic and *.ecore may co exist, the editor needs to support either on input, which is relatively easy with a "<xml?" peak. On save, the input format should be the default output, but the alternate should be selectable. More generally perhaps Xtext should always offer a SaveAs XML option.

See my last question ;-)

In summary:

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?

What persistent representations do you envisage for Emfatic?

The textual concrete syntax.

[And how do you plan to persist Emfatic comments in a *.ecore?]

I'ld like to support xmi based ecore only to migrate it once to the textual representation.


Back to the top