Just to clarify, I was thinking of text (that is UTF) persistence for all of these. In these sense that for some people apparently at least ;) xml is actually a text based language. Even for the dense data structures I was still thinking of text..imagine packing data into multiple blocks of tab-delimited tables for example.
On formatting, just a thought, but I'm struck by how formatting has actually become almost to be seen as damage in language. There is a settled canonical formatting scheme -- and as other's have pointed out, text indenting is not really a great place to express one's creativity. ;) This is true to the extent that I wish that the VCS had no respect for formatting, as for me it would avoid the annoyance of CVS reporting as changed all of my EMF code because I ran it through my formatter and for example got rid of missing brackets in if..else.. usages.
While I agree with you that traditional programs don't make good sense as database artifacts or what have you, I actually am taking a broader view of model instances. Think CDO for example, or a context where you want to do heavy inference across generated data. There all kinds of persistence and distribution schemes and so on could be needed and it would be good to have a generic way to make the decision about what scheme to use transparent to the user. But I don't think we're at the point of the evolution of these toolsets yet where we could make that kind of design decision anyway.
On Apr 8, 2010, at 12:40 AM, Sven Efftinge wrote: Hi Miles,
good points and of course it would be cool if we could have a (or any number of) textual representation for EMF models independent of how they are persisted. And as Ed W. outlined it is technically doable with Xtext. The point is that you won't get something you would want to use, because 95% of the time one is editing in text editors the model is corrupt and therefore not persistable (at least not in the way the ecore model needs it). It's just not a valid model. Also you will need to have a strategy to store the formatting. Similar to the diagram models in graphical languages you would need to have whitespace and comments stored in an extra model, with cross references and all those things or you always rely on auto formatting.
On the other side, what do I get with other storage formats ? Mainstream software development has been very successful with textual file based storage, and there are a lot of nice tools available which work nicely with text files. Also the vast majority of developers are comfortable with working with these tools. With other storage formats you'ld have to reinvent a lot of that. I see that especially in the modeling world a lot of people think it's a good idea to store source code in a database as opposed to a version control system. My perception is that this is a relict coming from graphical modeling tools which basically had no choice.
Given that we're talking about software development, I think using a concrete readable textual persistence format is an excellent solution. However, there might be environments where text files are not feasible. If you need a textual editor in such cases, you'll have to live with compromises and much more complexity (see above). It's doable but you should be sure that it's worth the effort.
Regarding the file extension, I agree that something closer to *.ecore would be better.
Cheers, Sven On Apr 7, 2010, at 8:25 PM, Miles Parker wrote:
A couple of thoughts from peanut gallery.. (I don't know if that is a good internationalized idiom or not!) On Apr 7, 2010, at 1:40 AM, Ed Willink wrote:
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.
That's certainly nice and simple, but does it always work?
As a general comment relating to the larger issue -- It seems to me that ultimately it would be neat and desirable to allow the user to specify both the editor *and* the persistence mechanism independently. That way -- assuming a persistence mechanisms is truly capable of consuming and producing generic Ecore resources -- one could simply refer to .ecore and use different editors and persistence as desired. I think this is important because for me philosophically **the thing that matters is not the persistence mechanism -- or even the user presentation -- but the representation**.
There might even be an analogous preference store to file associations that would allow one to set default preferences for a given extension. As one data point, I use both EMF.Edit and XText editors interchangeably for my models and that works (generally speaking) quite well.
As another general use case, I have one model that is very very dense -- it collects data from running models. XML as we know is a horrible way to represent dense information. (Besides being a horrible thing to have to read, and a horrible thing to maintain coherently..) So I'm thinking of (in the future!) creating an EMF resource implementation that just persists this model densely. It would be nice to allow users to have a very transparent way of persisting things.
I think it is an order of magnitude better to be able to edit any given model instance in a textual editor or graphical editor or even if desired some kind of raw format at whim. I've had really good experience for example with using the generated EMF.Edit editors with XText models interchangeably. Now I understand very well that that will not always work -- for example I am developing a separate xtext implementation for my meta-model -- but that's necause there are actual semantic differences that allow greater expressivity in the textual language. With Emfatic its basically a one-to-one mapping.
I don't think I'm making a controversial argument, but I want to emphasize it as a goal. And so while I don't necessarily care for the "Save as XML" idea, I think it would be good to think about ways to provide that kind of generic facility to users.
As a final note, if there is no way to simply use .ecore for both persistence types, I really don't think .emfatic is a good choice. I know that there is a history and it's a cute name, but the relationship to .ecore is just not that strong or obvious given that it is really just another representational dialect. Perhaps something like .etext or .ecorex..
Miles
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
|
