[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emft-dev] [EMFatic] Alignment with OCLinEcore
|
Hi Ed,
what limitation regarding "Only trivial rules can return a string" do
you refer to in Xtext? With data type rules you are free to do
basically anything what a "normal" parser rule allows, so I don't see
any drawbacks in them. Otherwise I've misunderstood your remark.
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.
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
