Re: [emft-dev] [EMFatic] Alignment with OCLinEcore

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Sven

On 27/03/2010 22:52, Sven Efftinge wrote:
> cool that you're implementing OCL in Xtext. We have similar plans for 
> EMFatic.
> We're working on a base language for Xtext (called Xbase) which allows 
> people to create new languages which extends and reused
> parts (or everything) of it. We want to implement an EMFatic editor 
> based on it.

I find Xbase an interesting source of ideas, but not directly useful for 
MDT/OCL and I'm temporarily bypassing the generic types that Xtypes 
would solve. [I'm likely to have a GSoC student doing direct Java code 
generation from OCL. It would be good to align this to support an 
interchange point for alternate 'action' languages such as Xexpr.]

I find that OCLinEcore at the model level is OCL in Emfatic at the 
concrete syntax level so there will be duplication between the editor 
I'm committed to providing as an Example in Helios and Emfatic in Iona. 
Long term it presumably makes better sense for OCL to depend on Emfatic 
rather than Emfatic on OCL, so the functionality, if not the 
implementation, should migrate. However I'm not sure there is really any 
point in confusing users with both a traditional Ecore/Emfatic editor 
and an enhanced Ecore/OCLinEcore editor. So perhaps Emfatic should 
provide the combined editor exploiting EssentialOCL.xtext to provide the 
semantic validation of OCL expressions.

The OCL embedded in EAnnotation is persisted in concrete syntax form. 
The editor parses an OCL expression to a tree but has to fight Xtext to 
revert it to a String again. Xtext does not allow a non-trivial rule to 
return a String!

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.

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.

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.

In summary:

How would you like to progress the Emfatic-OCL dependency?

What persistent representations do you envisage for Emfatic?

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

    Regards

        Ed Willink