Community
Participate
Working Groups
The runtime should optionally support the exchange of diagrams in alternative formats, such as the Diagram Interchange Specification for UML.
IMHO it should have been the foundation of all work! IMHO UML tools interoperate/echange models through XML Metadata Interchange (XMI) and not Diagram Interchange (since many do not adhere to it), at least, for me it makes more sense Seeing that this requirement is not going to be supported in the nearest future puts my interest/work in GMF in great doubt, hmmm
Well, is it about image export and copy-pasting to PowerPoint? Before interchanging diagrams, I would propose to decide, first, on model interoperability, i.e. with all combinations of XMI and UML versions (it is somehow 25+ variants) BTW, since GMF has in requirements also DSL and MS DSL Tools is even not compliant (I am not sure about whether they are comformant) to UML. And the rationale is quite understandable behind this Then how about BPMN, XPDL, BPML, BPEL and proprietory formats? I think it is not the question of specific implementation of standard but rather of pluggability, extensibility. Are extension points and docs already here? Where can I read on them? Guennadi Vanine
How did this go from Richard Grondback's statement of "GMF intends to provide support for custom serialization formats, with the Diagram Interchange Specification (XMI[DI]) being a likely default option" (news://news.eclipse.org:119/d9ribs$bfv$1@news.eclipse.org) to something which has such a low priority it'll probably never be implemented? Did the users all rise up and say in a unified voice that they'd much prefer to have to recreate all their work every time they changed tools? The project needs to do more than just pay lip service to standards conformance and this is a key piece.
This should be moved to the UML2 tooling subcomponent of the MDT project when formed.
(In reply to comment #4) > This should be moved to the UML2 tooling subcomponent of the MDT project when > formed. Removing the plan item keywords on the GMF Runtime as a result.
As an update, it's not clear that this issue should move to MDT in light of a conversation with Marko Boger of Gentleware at ESE. It was proposed that the DI Spec. could be revised to align closer with the GMF Notation model.
If supporting DI involves implementing a standard metamodel, that metamodel implementation should probably live in MDT (along with the other standard metamodels).
Changing component to runtime. I've not heard anything about the DI spec being updated to match the runtime notation model, nor do I expect we will implement interchange as it's currently written. Anthony, feel free to resolve as WONTFIX.
Hmmm, the much vaunted Eclipse/OMG collaboration was certainly short lived. Is there a proposal for a different standard diagram interchange format which will be implemented or is interchange of diagrams between tools not seen as a user requirement at all?
(In reply to comment #9) > Hmmm, the much vaunted Eclipse/OMG collaboration was certainly short lived. That's quite a conclusion to draw from the lack of interest (read: contribution) on this one specification. > Is there a proposal for a different standard diagram interchange format which > will be implemented or is interchange of diagrams between tools not seen as a > user requirement at all? As indicated in comment #6, there was simply a conversation at ESE 2006 on the subject of revising the specification. And as mentioned in comment #8, I've heard nothing on the topic since. Has anyone? Are you volunteering to contribute to this effort?
The DI specification is to be superseded by the Diagram Definition specification, which is currently in the RFP stage - see http://www.omg.org/cgi-bin/doc?ad/2007-9-2. I believe there was activity around this specification during the OMG technical meeting in March, and the last I heard, it was being based on GMF... so I'd say that Eclipse/OMG collaboration is still very much alive, on this and (many) other fronts.
(In reply to comment #10) > Are you volunteering to contribute to this effort? Sure, I'll volunteer. I don't have the corporate backing of an IBM or a Borland, so the contribution will be smaller (and come out of my own pocket), but it's too critical a task to just drop. I mean what could be sillier than a "standard" graphical modeling language that has no way to interchange the drawings? Where would be a good place to begin? I was just reading about Gentleware's long standing commitment to open source (http://www.gentleware.com/eclipse.html) and since they're not only Eclipse Foundation members, but also apparently involved in the OMG diagram work, I bet they'd love to contribute to jump start this effort. How about if I make my first task hitting them up for a contribution? Who should I have them coordinate their contribution with on the Eclipse Foundation end of things? According to the timetable in the RFP that Kenn provided initial submissions for the next generation diagram interchange standard are due May 26, 2008. Is the Eclipse Foundation making a submission? Would it be helpful if I coordinated one? Who has material that they'd like included? What about soliciting contributions from other UML tool vendors? Has that been tried? Clearly since IBM controls both Rational and Eclipse they would have contributed by now if they thought it was in their strategic interest, but what about some of the others? Who has other ideas on how to progress this? In 2+ years, it's gone from "likely default" to P5 to WONTFIX candidate. We need to reverse this trend.
(In reply to comment #12) > What about soliciting contributions from other UML tool vendors? Has that been > tried? Clearly since IBM controls both Rational and Eclipse they would have > contributed by now if they thought it was in their strategic interest, but what > about some of the others? > To be clear, IBM does NOT control Eclipse. They are, however, involved in a submission for the DD specification, if I'm not mistaken...
(In reply to comment #12) > (In reply to comment #10) > > > Are you volunteering to contribute to this effort? > > Sure, I'll volunteer. No kidding? That's really great, thanks. It's not very often we see a positive reply to that question. I don't have the corporate backing of an IBM or a > Borland, so the contribution will be smaller (and come out of my own pocket), > but it's too critical a task to just drop. I mean what could be sillier than a > "standard" graphical modeling language that has no way to interchange the > drawings? Funny, the UML existed for years without the possibility to exchange diagram information, which left a lot of folks asking the same question. However, afaik the DI spec was only implemented by Gentleware, which doesn't do much for the exchange story. > > Where would be a good place to begin? > > I was just reading about Gentleware's long standing commitment to open source > (http://www.gentleware.com/eclipse.html) and since they're not only Eclipse > Foundation members, but also apparently involved in the OMG diagram work, I bet > they'd love to contribute to jump start this effort. How about if I make my > first task hitting them up for a contribution? Who should I have them > coordinate their contribution with on the Eclipse Foundation end of things? That would be helpful, as I'd be interested to hear their opinion about the Diagram Definition RFP. It may be that it's more sensible to just wait for this specification to become "real" and align with it, particularly as it may supersede the DI (though the RFP also mentions interop with DI). > > According to the timetable in the RFP that Kenn provided initial submissions > for the next generation diagram interchange standard are due May 26, 2008. Is > the Eclipse Foundation making a submission? Would it be helpful if I > coordinated one? Who has material that they'd like included? The Eclipse Foundation doesn't actually make submissions. Many of the members of the Foundation are members of the OMG, however (Kenn has some nice Venn diagrams of the reality). > What about soliciting contributions from other UML tool vendors? Has that been > tried? Clearly since IBM controls both Rational and Eclipse they would have > contributed by now if they thought it was in their strategic interest, but what > about some of the others? I expect that all organizations using GMF would back a submission that is based on the current implementation we are using. > Who has other ideas on how to progress this? In 2+ years, it's gone from > "likely default" to P5 to WONTFIX candidate. We need to reverse this trend. Frankly, it comes down to who is asking for interchange... I initially submitted this bug as it was on the long list of GMF "wish list" items when we started. Given that this bug has had little activity, and that the Diagram Definition RFP seems like a more complete solution to the problem, I'd say close this bug and focus on that effort.
Maged Elaasar at IBM is working on the specification at the OMG this year. We will look at taking a run at adopting for Io.
[GMF Restructure] Bug 319140 : product GMF and component Runtime was the original product and component for this bug
Papyrus has an implementation of UML DI: https://www.eclipse.org/forums/index.php/t/1068142/ http://download.eclipse.org/modeling/mdt/papyrus/updates/releases/mars/extra Maybe it can be merged into UML project? UML DI is a part of OMG UML 2.5 specification.
