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

[Cédric Brun <cedric.brun@xxxxxxx>]

Hi,

>
> It is likely that we will use the previous file extension of Emfatic
> and not *.ecore. Furthermore there is usually no need (except in the
> context of ATL) to do a "Save as xmi" as the content of the file is
> exposed as an EMF resource and fulfills its contract.
>
Just to avoid misconception spreading, I just had a try with Helios
Xtext + ATL and the later is now "EMF Resources" friendly, I wrote  a
basic refactoring on a fowlerdsl state machine and applied it on a
model. The resulting serialization is badly indented though (everything
on one line).



> Regards,
> Sebastian
>
>
> On 07.04.2010, at 07:47, Ed Willink wrote:
>
>> 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
>>
>> _______________________________________________
>> emft-dev mailing list
>> emft-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/emft-dev
>
> _______________________________________________
> emft-dev mailing list
> emft-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/emft-dev
>