- Yes, MOF is about dead. That's really sad. I didn't even know it was ill!
- It may influence it, but both will stay. This sounds a bit too future tense to me. EMOF and Ecore are effectively equivalent---we can read and write Ecore as an EMOF serialization---and that's not an accident. MOF was split into EMOF and CMOF (essential and complete) because of Ecore's influence. When we started work on EMF, MOF seemed to have a lot of nonessential things, so we eliminated those.
- EMF will never supplant MOF, MOF is great. Since Ecore is an implementation of EMOF and existed before EMOF, I'll be just as happy if we compliment MOF rather than supplant it. If MOF is great, so is EMOF, and so is Ecore. Transitivity is such a useful property!
- EMF is just for Java, it is too specific, MOF is great. Well, EMF is clearly a MOF implementation targeted to Java. I'm not sure if a Java implementation can be too specific for Java, but if so, I guess it could also be not specific enough, or it could hit the Goldilocks target of being specific but not too specific. Coincidentally, Reinhold Bihler is working on a .NET version of EMF and I know other folks have generated C from it. His version will be just for C# so it might be too C# specific but I expect it will be just specific enough. I'm still waiting to find out from Mike if a C# project can be hosted at Eclipse. That would be a first I think...
Like so many other folks, I'm very much looking forward to Eclipse Summit Europe next week. The Architecture Council group, of which I am a member, is planning to have dinner, which will of course accomplish next to nothing and hence will completely live up to the expectations based on the council's past performance. Oops, did I say that out loud? Just a little joke! Besides, I'm just quoting Bjorn who's never afraid to say what needs to be said. In all seriousness, the newly reformed council has yet to meet, so time will tell if we can become a functional body. If we can just become good mentors for the community we will have taken a positive step in the right direction.
On Tuesday there will be an all day Eclipse Modeling Symposium. Last year's symposium was way cool, so I'm particularly looking forward to this one. On Wednesday there are all day meetings about Big Models to look closely at issues of how EMF can best help support a massive collection of interrelated models. And by the way, don't ever Google for "big models". Oh my eyes. Some images are hard to erase after having been seared onto your retinas. My partner in crime, Rich Gronback, and I will be giving a cool demo. And of course modeling is ever so popular in Europe so there will be cool talks about oAW and compare. I'd never heard about Medany Platform before, so I'll be interested to find out about that!
Lots of people I've never met will be there, and meeting people is more than half the fun. I'm particularly excited to meet Tom Schindl. He's so incredibly helpful on the newsgroups and is doing such cool things. I can't wait.
So no garden pictures this time, but I'll leave you with this photo I took a few years back in Grenda with a rainbow to remind us that diversity in our community is the key to its long term growth:
Posts
6 comments:
ha ha. Your comment about big models reminds me about the time I googled for "master slave" with respect to database replication. I was also quite tramautized by the result.
Please bring me a doggie bag back from the Architecture council dinner :-(
Let's not forget the spam (resumes, headshots) I was getting when we first started the Modeling Corner and people seemed to think we were a talent agency. Good times.
If we see it from the MDA layered architecture perspective, the EMF metamodel clearly seats on the M2 layer while the MOF meta-metamodel is on the M3 layer. So, I am not sure why EMF will replace MOF.
I guess EMF does such a good job isolating the M3 layer that people just forget about MOF.
The M1 layer puts food on Ed's table and M0 layer puts food on ours ;-)
I dont think the last comment is correct.
In my view:
- M0 has application objects.
- M1 (model) has classes in a model of application. M0 elements are instances of M1 elements.
- M2 (meta model) has concepts used to define language in which M1 model is created (say, UML meta model). M1 elements are instances of M2 elements.
- M3 (meta meta model) has concepts used to define models at M2 level. M2 elements are instances of M3 elements.
Thus EMF, and MOF both appear to be at level M3.
Ed, would you please be able to clarify..?
Anil,
In my long experience, no good ever comes from discussing the OMG's hierarchy of meta levels. The common misconception is that these levels are absolute and that there are exactly four. Neither is the case. The level is relative to some context and the progression is potentially infinite.
Ecore exists at all the levels. Specifically, when I create an EClass instance named X in the Sample Ecore Editor, it's just an instance, i.e., data at M0, just like any other instance data I might edit. When I invoke "Create Dynamic Instance..." for it, then it's suddenly apparent that it is also an M1 instance with respect to the created dynamic instance. Of course Ecore is also used to define Ecore itself, so it's also an M1 instance with respect to the EClass X in the Sample Ecore Editor as well an M2 instance with respect to the dynamic instance we created from that EClass X. Ecore is also used to define UML2 which you assert to be M2, so therefore Ecore is also M3 from that perspective.
Now consider XML Schema. It's used to define the structure for M0 XML instances. Therefore it's M1. But there's an XML Schema for XML Schema, so therefore XML Schema is also M2. The W3C didn't seem to know they needed an M3 at all, but then we defined a model for it with Ecore, so Ecore is M3 again. Of course we might have defined a model for XML Schema using UML2, which would then be M3, and of course we have an Ecore model for UML2, which would then be M4.
It's all very interesting but all that matters is that there are instances and there are descriptions/models of instances. Since those descriptions/models are themselves instances, we can digress infinitely. To prevent that, we eventually end up with a model that's self describing. That's typically the case by the time we digress two times and rarely takes more than three digressions.
Post a Comment