I absolutely agree that we need to get out of the XML parsing business as soon as humanly possible, but NetBeans MDR, as it stands today, isn't going to provide us with a path to UML 2.x Diagram Interchange. It doesn't support the prerequisite versions of MOF and XMI.
Tom > -----Original Message----- > From: Linus Tolke [mailto:[EMAIL PROTECTED] > Sent: Monday, September 18, 2006 3:20 AM > To: [email protected] > Subject: RE: [argouml-dev] Keeping zargo file compatible with > previous versions of ArgoUML > > > Hello Bob! > > I would prefer that we do not have to write and maintain a > diagraminterchange.tee script and a Parser for this. We have > had problems with this as long as I remember (and we still > do). I am not sure of the details of the problems but my > guess is that they come from inconsistencies between the tee > script and the Parser. > > If we were to go for a solution where the XML-generator and > XML-parser are generated by MDR from a model, then there > would no longer be any inconsistencies. > > What we need is > - the model - it can be easily drawn from the Diagram > Interchange 2.0 specification, and converted to MOF. > - a glue between GEF and the MDR-generated code that together > with information from the UML model present an editable > diagram from the information in MDR. This would then be the > code of the Diagram Subsystem. > > If you say "We will write diagraminterchange.tee and a new > parser." I am thinking years of bugfixing and never getting > it quite right. > > /Linus > > > -----Original Message----- > > From: Bob Tarling [mailto:[EMAIL PROTECTED] > > Sent: den 17 september 2006 21:05 > > To: [email protected] > > Subject: Re: [argouml-dev] Keeping zargo file compatible > with previous > > versions of ArgoUML > > > > GEF is not aware of MDR and there are no plans that it should be. > > > > GEF is a graph modelling system but it is the responsibility of the > > application to save and restore those models in whatever format is > > required for that application. > > > > For ArgoUML that is the diagram interchange format. GEF does not > > prevent this work being done in ArgoUML. > > > > We can write diagram interchange in a simlar way as we do > for pgml by > > writing a diagraminterchange.tee script (or use some more standard > > template library such as velocity, freemarker or jamon). We > will have > > to write a parser similar to PGMLStackParser to read the data back. > > > > This would not effect any subsystem dependencies. > > > > Bob. > > > > On 9/13/06, Linus Tolke <[EMAIL PROTECTED]> wrote: > > > Replying to an old mail... > > > > > > A stable and formal API and persistence format sounds very good. > > > > > > On the other hand, I agree with whoever mentioned it (Tom I think) > that > > > we are approaching the point where the next change to the save > format > > > concerning the save format of diagrams should be a move to the UML > 2.0 > > > Diagram Interchange format. > > > > > > With risk of restarting the very confusing discussion from last > > > summer... > > > > > > If we go for UML 2.0 Diagram Interchange format then it should not > be > > > very far fetched to put the diagram information in MDR > and have it > > > parameterized by a Diagram Interchange meta-model. If that is the > case, > > > two groups of questions arise: > > > > > > Is GEF ready for this? Can GEF work while having things > like list of > > > figures, color, size, position, and sub-parts accessed from a > > > repository? Can GEF accept events with changes of things in the > > > repository? Can GEF work with sizes and positions in floats? > > > > > > How does this affect the relationship between the involved > subsystems in > > > ArgoUML: Model, Model MDR implementation, Diagrams, and > Persistence? > > > > > > Both these questions are for you, Bob, to answer. A clear "Yes" on > the > > > first group of questions is required, otherwise I'd say, > GEF is not > > > ready for this. > > > > > > /Linus > > > > > > > -----Original Message----- > > > > From: Bob Tarling [mailto:[EMAIL PROTECTED] > > > > Sent: den 2 september 2006 15:28 > > > > To: [email protected] > > > > Subject: [argouml-dev] Keeping zargo file compatible > with previous > > > > versions of ArgoUML > > > > > > > > There are various reasons why it is not possible to load a zargo > file > > > > from a current release in a previous version of ArgoUML. > > > > > > > > I think there are 2 major problems that cause regular change. > > > > > > > > 1. Fixing errors in save due to previous ArgoUML bugs > > > > > > > > Some of these fixes must not be repeated. By saving a > persistance > > > > version we ensure that a fix is run once and only once when we > know > > > > that it is required. > > > > > > > > 2. Use of PGML and reflection to save and load diagrams > > > > > > > > The current method of saving diagrams as PGML means > every time we > > > > adjust the composite make up of a Fig then persistence format > differs. > > > > > > > > The problem comes if we have introduced some new Fig or > refactored > the > > > > name or package of an existing Fig. For the current ArgoUML to > read > > > > previous projects we have no problem as the upgrade XSL adjusts > the > > > > project for these changes. > > > > > > > > However when a previous version of ArgoUML is used to > load such a > > > > project it will attempt to create each Fig by > reflection using the > > > > class names stored in the PGML. Obviously it won't find > these and > > > > BANG. > > > > > > > > In the past this tended to mean some random exception being > presented > > > > to the user, the user creates issues in the database > which we have > to > > > > investigate and our reply was always upgrade to latest version. > > > > > > > > This is why I introduced the persistence version. A value that > > > > increments each time such a change has taken place. > Instead of an > > > > exception the user now sees a message asking them to upgrade. > > > > > > > > I hadn't previously seen this as a problem because ArgoUML is > becoming > > > > more stable and we want to push users towards that more stable > > > > release. I've tried to make changes as gradual as > possible saving > any > > > > more major changes until after a stable release of ArgoUML. > > > > > > > > Changes to the Fig structure are certainly likely. > Issue 3238 and > > > > issue 4426 spring to mind immeditely. > > > > > > > > We have problems now though of requirements of > > > > http://argoeclipse.tigris.org > > > > > > > > The argoeclipse project is not planning to keep step > with ArgoUML > > > > releases. They are keeping to their own schedule. This > means that > the > > > > latest version of argoeclipse may not be able to read a > save file > from > > > > the latest version of ArgoUML. > > > > > > > > The only solution I see is to move to a more formal fixed format > than > > > > PGML for which we need to make a reader and writer that will be > > > > modified for each version. The logical choice with be the OMG > diagram > > > > interchange format but I was hoping not to do such major change > for a > > > > long time. > > > > > > > > With all of the above commments I'm not so sure if it's worth > spending > > > > time on issue 4431. This will not solve the requirements of > > > > argoeclipse as they will have compatability problems anyway. > > > > > > > > But it seems we have a catch 22. The requirements is to > stabalise > the > > > > persistence format but in order to do that we need to > change the > > > > persistence format. > > > > > > > > How do we go about this? > > > > > > > > As a slight aside. There has been some talk a couple of months > back > > > > about moving to ArgoUML 1.0. > > > > > > > > To my mind the most important thing for that release is not the > bug > > > > count but a stable and formal API and persistence > format. I think > we > > > > have some way to go for that. Is that what we should be > concentrating > > > > on now? > > > > > > > > Bob. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
