[
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.
Regards,
Sven
